Manuel brought up a recent regression shown by ICA in cc1 and cc1plus. http://linuxfromscratch.org/pipermail/lfs-dev/2007-February/059037.html
I did some investigation on this. I reproduced it running jhalfs, but it didn't show up in my own scripts. I've got a few DIY tweaks in there, so I started testing out things. First, I thought maybe bison/flex had made themselves needed again, but that didn't seem to be the case. Then I remembered one other thing Greg recently tweaked for more purity. http://www.diy-linux.org/pipermail/diy-linux-dev/2006-December/000967.html One of the things that currently doesn't happen in the chroot toolchain adjustment for LFS is making gcc prefer the new headers in /usr/include. If you add '-v' to the sanity check output, you'll see that it's still looking in /tools/include. So, I added in the -isystem /usr/include to the gcc specs. Lo and behold, there was a difference. I don't know what would cause this difference. Either something with using the new kernel headers or something with gcc-4.1.x since this was never an issue before when we continued using the headers in /tools/include. Now I think I see the issue. We don't apply the glibc upstream patch in Ch. 5. This patch touches two headers that may be included into built sources: features.h and libio.h. I still have to spin a full build to be sure that this does fix the regression, but I thought I'd throw it out there. Although it may fix things to patch glibc in Ch. 5, I'd prefer to make gcc use the headers in /usr/include. That seems like the right thing to do. More info as it arrives. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
