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

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

zoltan wrote:
> 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...
> Thanks,
> zoltan

I think I may have just found my answer...so I'll answer my own 
question, ridiculous as that is...

THe specs patch that is applied in ch. 5 is what is responsible for 
altering the system include directory.  So if I want to disable that, 
I'll go investigate the files that that patch is changing.

But this does bring up interesting side-note, which I'm not sure is 
emphasized in any of the lfs books:  compiling ch. 5 must be done on the 
same C-library based system as the one that is being installed in lfs; 
i.e.: glibc.  So for instance, someone trying to build lfs (glibc-based 
version, as in the book) on a uClibc-based system would run into the 
exact same issues as I did...

More information about the lfs-support mailing list