gcc-3.3.1 still looks in /usr/include instead of --with-local-prefix=...

zoltan 6zoltan8 at comcast.net
Mon Nov 22 23:22:06 PST 2004

I'm trying to build lfs using uClibc (got glibc down pretty good), and 
have run into some issues, most of which I've gotten around.  Except one:

After the initial install of gcc in ch. 5, first pass, even when 
compiling a test program, the system include directory is still 
/usr/include.  I was under the impression that the 
--with-local-prefix=... option to the ./configure command would switch 
the system include directory.

Now the effect of this doesn't become apparent until expect-5.39 of ch. 
5, which moans greatly about stuff included from 
/usr/include/sys/stropts.h, no doubt because uClibc has no such header 
file, and the features.h is also different.

To make matters more interesting, if I skip tcl, expect, and dejagnu in 
ch. 5, and proceed to the 2nd pass of gcc in ch. 5, gcc compiles fine 
(again with the --with-local-prefix=...), but then if I use that 
resultant gcc to go back and compile expect (as well as my test 
program), the system include dirs. are then exactly what I set them to 
with the --with-local-prefix=... option.

So I conclude that this is really bizarre, and my only guess is that the 
first pass of gcc's --with-local-prefix=... is somehow affected by the 
static flag, or the bootstrap build, and hence may be a gcc bug that is 
only exposed under these conditions.

But wait, there's more...then when I proceed to ch. 6 and build gcc 
there (again after uClibc), even though I still specify the 
--with-local-prefix=... (I did want to have to usable toolchains and 
associated headers present on my system, in parallel, with glibc-based 
system in the usual place, and the uClibc-based system under 
/opt/uClibs-0.9.26/...), gcc then reverts back to its undesirable 
behavior of going back to /usr/include as the system include directory.

Anybody know how to alter the system include directory?  Is it a 
compilter thing, or a C library thing, I'm not even sure of that...


More information about the lfs-support mailing list