Greg Schafer wrote:
>> Author: jhuntwork
>> - Use --disable-multilib in final gcc and binutils
>
> Why binutils? It serves no purpose there.
I did notice that it didn't make a difference with binutils, but I must
admit that this was a case of working from CLFS. I started by taking
notes of what they had and adapting for LFS. When I noticed that I
forgot this for final GCC in chapter 6 (the build crashed looking for
unnecessary stub headers), I just dumped in the command for binutils, as
well, assuming that CLFS knew what they are doing. Assumptions...
I can see by grepping that binutils seems totally unaware of this
switch. Will remove...
>> - Explicitly tell Glibc to use /lib and /usr/lib, instead
>> of defaults of /lib64 and /usr/lib64
>
> Again, why do it? The symlinks take care of this. It's just complicating
> the build unnecessarily IMHO.
This one I deliberated with for a bit. I finally opted for the switches
to Glibc for a couple of main reasons:
* Elsewhere, (in the gcc patches, for example) we are explicitly
forcing /lib to be the location of the 64-bit libraries. For the sake of
consistency in the system, it seemed better to have Glibc configured to
look there (and install there) by default.
* If Glibc is configured for /lib and /usr/lib, then if for some the
reason the symlinks disappear, the toolchain remains relatively intact.
If Glibc is left to its defaults, when the {/usr,}/lib64 links
disappear, the linker is broken immediately. It seems more robust to
have the symlinks there for compatibility only, than for them to be
absolutely depended upon. Of course, since I am still in the midst of
testing, I can't say definitively that the symlinks aren't absolutely
necessary either way.
Feel free to prove me wrong on the above. I am definitely learning as I
go and pointers from those already through this route are always welcome.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
