So, I'm seeing that you have the aforementioned switches in both pass 1 and pass 2 gcc and I'm trying to understand exactly why.
Here's the changeset that introduced them: http://wiki.linuxfromscratch.org/lfs/changeset/9349 And here's the ticket that started that ball rolling: http://wiki.linuxfromscratch.org/lfs/ticket/2723 I don't think those switches are necessary for either scenario. For pass 1, we're building a throwaway cross-compiler that is intended to run on the host system. If it gets linked against libraries on the host, so what? Those libraries will just be for runtime of that one compiler and then will be gone by pass2 of gcc and should not affect at all the building of glibc or the next versions of binutils and gcc. Now granted, leaving those switches in doesn't hurt, but the explanation currently given in pass 1 is misleading. It says: "These switches prevent GCC from building against the PPL and CLooG libraries which may be present on the host system, but will not be available in the chroot environment." Doesn't matter. That gcc won't be present in the chroot environment either. For pass 2: it gets built by the pass 1 compiler, but that should by that point already be configured to look exclusively in /tools for libs and headers. There is no way it can link against a cloog or ppl on the host. If it does, there's a problem with the instructions or with the way the user has followed the instructions. So given that... I don't see a need to have those switches for either pass 1 or pass 2. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
