When GCC builds, it creates and stows away internally an "include-fixed" directory containing "fixed-up" versions of the system headers files on the system it was built with. This feels wrong to me: it gives GCC a hard dependency on the specific set of system header files present when GCC was built. It's potentially incorrect even for straightforward installations, where a newer header file provided with a package upgrade might be ignored in preference to an older "fixed" version. However, when attempting to create a relocatable version of GCC it's even more problematic. In particular, it seems very wrong (and, in fact, it often doesn't work) to search the include-fixed directory when the user has specified a --sysroot flag, choosing to compile against a wholly different set of headers and libraries than the ones on the host system. I think that the include-fixed directory should be associated with the sysroot, somehow, not embedded deeply into the compiler internals, and when --sysroot is provided there should be a well-known location inside the sysroot which will be searched for include-fixed headers. Also, the fixinc.sh script should be better documented and enhanced to be simpler to run, so that it can be invoked more easily against a given sysroot to construct the include-fixed directory for that sysroot.
On Wed, 11 May 2011, psmith at gnu dot org wrote: > I think that the include-fixed directory should be associated with the sysroot, It should be associated with each system include directory (sysroot or otherwise) - so there should be a fixed version of /usr/local/include, searched immediately before /usr/local/include, and likewise for /usr/include. But there are certainly sysroot uses where include-fixed is still relevant - where the sysroot is based on a copy of that used when GCC was built, but with extra libraries added. (That's the case of sysroots that works most reliably for other reasons as well; GCC's runtime libraries get configured depending on the libc libraries and headers present when GCC was built, and in some cases the headers affect the configuration of GCC itself as well as GCC's libraries.) http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02088.html http://gcc.gnu.org/ml/gcc/2004-11/msg00255.html
(In reply to joseph@codesourcery.com from comment #1) > On Wed, 11 May 2011, psmith at gnu dot org wrote: > > > I think that the include-fixed directory should be associated with the sysroot, > > It should be associated with each system include directory (sysroot or > otherwise) - so there should be a fixed version of /usr/local/include, > searched immediately before /usr/local/include, and likewise for > /usr/include. This sounds like an agreement that some form of change would be worthwhile; I'm going to take that as confirmation. > But there are certainly sysroot uses where include-fixed is > still relevant - where the sysroot is based on a copy of that used when > GCC was built, but with extra libraries added. (That's the case of > sysroots that works most reliably for other reasons as well; GCC's runtime > libraries get configured depending on the libc libraries and headers > present when GCC was built, and in some cases the headers affect the > configuration of GCC itself as well as GCC's libraries.) > > http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02088.html > http://gcc.gnu.org/ml/gcc/2004-11/msg00255.html Shouldn't it be possible to come up with a solution that still supports those cases while also fixing the cases Paul described?
(In reply to Eric Gallager from comment #2) > (In reply to joseph@codesourcery.com from comment #1) > > On Wed, 11 May 2011, psmith at gnu dot org wrote: > > > > > I think that the include-fixed directory should be associated with the sysroot, > > > > It should be associated with each system include directory (sysroot or > > otherwise) - so there should be a fixed version of /usr/local/include, > > searched immediately before /usr/local/include, and likewise for > > /usr/include. > > This sounds like an agreement that some form of change would be worthwhile; > I'm going to take that as confirmation. > > > But there are certainly sysroot uses where include-fixed is > > still relevant - where the sysroot is based on a copy of that used when > > GCC was built, but with extra libraries added. (That's the case of > > sysroots that works most reliably for other reasons as well; GCC's runtime > > libraries get configured depending on the libc libraries and headers > > present when GCC was built, and in some cases the headers affect the > > configuration of GCC itself as well as GCC's libraries.) > > > > http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02088.html > > http://gcc.gnu.org/ml/gcc/2004-11/msg00255.html > > Shouldn't it be possible to come up with a solution that still supports > those cases while also fixing the cases Paul described? Joseph, can you think of one?
Well, I suppose you could have a new option to say what set of fixed headers to use, in the case where your sysroot is not based on the one used when building GCC.