Hi Marcin. Would you consider passing --enable-poison-system-directories to the cross compiler configure? This makes the '-Wpoison-system-directories' option available which warns you if the cross compiler picks up a library or header file from /usr instead of the cross-build environment.
I'm talking with someone who's looking at using the Linaro compiler and had a strange error due to picking up the host crtn.o. Having this warning would of tracked down the problem faster.
-- Michael
Dnia piątek, 8 października 2010 o 02:52:13 Michael Hope napisał(a):
Hi Marcin. Would you consider passing --enable-poison-system-directories to the cross compiler configure? This makes the '-Wpoison-system-directories' option available which warns you if the cross compiler picks up a library or header file from /usr instead of the cross-build environment.
Sure, I can enable it. In OpenEmbedded we use stronger version - build which tried to use system headers gave errors.
I'm talking with someone who's looking at using the Linaro compiler and had a strange error due to picking up the host crtn.o. Having this warning would of tracked down the problem faster.
Regards,
On 08.10.2010 02:52, Michael Hope wrote:
Hi Marcin. Would you consider passing --enable-poison-system-directories to the cross compiler configure? This makes the '-Wpoison-system-directories' option available which warns you if the cross compiler picks up a library or header file from /usr instead of the cross-build environment.
How does this relate with the primary goal of getting performance improvements into the Linaro GCC for ARM? This is not even in GCC trunk, and introducing an option which is not recognized by anybody else introduces a potential for regressions, regardless the issues it is supposed to fix.
This specific option may only be set for cross builds, but there are other changes/backports in the Linaro GCC which do break package builds in the Ubuntu archive.
With my Ubuntu distribution hat on, these are regressions caused by the Linaro GCC changes, which cause effort to find, analyse and fix, either in Linaro GCC or in the package. The question is if the benefits of a change in Linaro GCC out-weights the efforts required to fix the package builds, for all architectures where Linaro GCC is used for the builds. We did make this decision for 4.4, but we should re-evaluate this maybe for 4.5 and definitely for 4.6 for the native Ubuntu builds.
Matthias
+++ Michael Hope [2010-10-08 13:52 +1300]:
Hi Marcin. Would you consider passing --enable-poison-system-directories to the cross compiler configure? This makes the '-Wpoison-system-directories' option available which warns you if the cross compiler picks up a library or header file from /usr instead of the cross-build environment.
That is correct for libraries, and probably headers for the time being, but as soon as we start installing to multiarch paths it will become incorrect for headers and would at least need adjusting for libraries.
Wookey
On Fri, Oct 8, 2010 at 1:48 PM, Wookey wookey@wookware.org wrote:
+++ Michael Hope [2010-10-08 13:52 +1300]:
Hi Marcin. Would you consider passing --enable-poison-system-directories to the cross compiler configure? This makes the '-Wpoison-system-directories' option available which warns you if the cross compiler picks up a library or header file from /usr instead of the cross-build environment.
That is correct for libraries, and probably headers for the time being, but as soon as we start installing to multiarch paths it will become incorrect for headers and would at least need adjusting for libraries.
What do you mean by incorrect? -Wpoison-system-directories warns if an include file is picked up from /usr/include, /usr/local/include, or /usr/X11R6/include. My original email regarding /usr was incorrect.
-- Michael
linaro-toolchain@lists.linaro.org
-
Marcin Juszkiewicz -
Matthias Klose -
Michael Hope -
Wookey