Greg Schafer wrote:
>> Comment (by [EMAIL PROTECTED]):
>>
>> Trying again to see if I can get the formatting correct.
>>
>> Not sure what to think about this one. I double-checked and confirmed that
>> the fixinc.sh sed was ran. Indeed it was. But running the header sanity
>> check after building Chapter 6 GCC, I get this returned:
>>
>> {{{
>> #include <...> search starts here:
>>
>> /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include
>> /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed
>> /usr/include
>> }}}
>>
>> I suppose I'm not seeing the /usr/local because I have no need for that
>> directory and do not create it, therefore it doesn't exist on my system.
>> What I find strange is the "include-fixed" directory (which is populated
>> with 3 files):
>> {{{
>> -rw-r--r-- 1 root root 750 Sep 26 18:12 README
>> -rw-r--r-- 1 root root 3470 Sep 26 18:12 limits.h
>> -rw-r--r-- 1 root root 330 Sep 26 18:12 syslimits.h
>> }}}
>>
>> Is this normal behavior? Or did I somehow screw something up with the
>> fixincludes process?
>>
>
> It's normal for GCC 4.3 and you definitely want the include-fixed dir. The
> LFS text needs to change. Follow all the links in this thread for some
> background info:
>
> http://sourceware.org/ml/libc-alpha/2008-01/msg00067.html
>
> Regards
> Greg
>
Ugh! I forgot about that, and I just fixed this same problem in glibc
two weeks ago. Thanks for the link Greg! I went looking for the
rationale behind this, and this:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg02038.html
Simplicity for who? I'm not sure the unconditional move is sane. Sure
it is only one, but it broke glibc a few weeks ago. Probably not likely
to break too many packages I guess. IMO it would have been better to to
do the extra scripting to move limits.h into the gcc include directory
and include_next <limits.h> directly if fixincludes did not run or cross
compiler was used. mkheaders could determine if it needs to be
removed/modified for new fixed headers.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
