gcc-3.3.1 still looks in /usr/include instead of --with-local-prefix=...
6zoltan8 at comcast.net
Mon Nov 22 23:41:22 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...
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