As some of you know I came to Linaro from OpenEmbedded project. In OE we cross compiled by default and to make it more easy we had one nice addon to gcc.
When host includes were used gcc errored out with "CROSS COMPILE BADNESS: /usr/include used" style message. Patch is present in metadata:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/gcc/gcc-4.4.... no-host-includes.patch
Some time ago replacement was announced on OE mailing list:
http://thread.gmane.org/gmane.comp.handhelds.openembedded/34169
In that thread Khem Raj mentioned -Wno-poison-system-directories which is available in CSL toolchains.
I would like to get that functionality in our cross compiler as this nicely shows problems in packages. I got hit by that in eglibc when it fails with:
In file included from ../ports/sysdeps/arm/libc-tls.c:20:0: ../csu/libc-tls.c: In function ‘__libc_setup_tls’: ../csu/libc-tls.c:194:1: error: ‘__ARM_NR_set_tls’ undeclared (first use in this function) ../csu/libc-tls.c:194:1: note: each undeclared identifier is reported only once for each function it appears in
just because unistd.h used from host instead from target includes.
Regards,
+++ Marcin Juszkiewicz [2010-07-15 09:59 +0200]:
As some of you know I came to Linaro from OpenEmbedded project. In OE we cross compiled by default and to make it more easy we had one nice addon to gcc.
When host includes were used gcc errored out with "CROSS COMPILE BADNESS: /usr/include used" style message. Patch is present in metadata:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/gcc/gcc-4.4.... no-host-includes.patch
That is a good idea but if multiarch paths are used for headers then that is not usually an error. (most headers are arch all anyway so will/can be shared). Debian is different to OE in that only packages in version sync with host can be cross-built (in multiarch method), so shared headers is OK. Obviously headers that are actually arch-independent have different paths and chaeck for those would be very handy.
Wookey
Dnia czwartek, 15 lipca 2010 o 18:08:44 Wookey napisał(a):
That is a good idea but if multiarch paths are used for headers then that is not usually an error. (most headers are arch all anyway so will/can be shared). Debian is different to OE in that only packages in version sync with host can be cross-built (in multiarch method), so shared headers is OK.
We will have to talk about multiarch during next week as for now it is something which I ignore.
Obviously headers that are actually arch-independent have different paths and chaeck for those would be very handy.
Sure - tell that to asm/unistd.h which is ARCH dependent... it took me a bit to find out why eglibc does not want to build for me.
Regards,
linaro-toolchain@lists.linaro.org
-
Marcin Juszkiewicz -
Wookey