Tushar Teredesai wrote:
> It found the libgcc_s in
> /tools/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../libgcc_s.so.
<snip>
> Confirmed. Though it did come as a surprise. When I tried the test
> that you mentioned, it found the glibc libraries in /tools/lib, not in
> /usr/lib. I checked the command that was passed to ld and there was no
> -L/tools/lib. so it should have just found the libs in /usr/lib and
> /lib (as per the LIB_PATH).
No. It's more complicated than that :-/ GCC also has a say in the library
search path too. This is why the startfile_prefix_spec hack to GCC makes
it (mostly) do the right thing.
Alrighty then.. so the current LFS unstable has a flawed build method. ie:
it's regressed back to where it was before the startfile_prefix_spec hack
first went in. Like I said tho', there is enough redundancy in the 2 phase
build method approach to render this flaw relatively harmless for "by the
book" builds. But IMHO it's risky and dangerous and should be fixed. Here
are the options:
1. Leave things exactly as they are ie: with a flawed build method. The
Ch 6 GCC & Binutils link against the wrong libc (ie: the one in /tools)
2. Reinstate the startfile_prefix_spec hack. If this happens, the
libgcc_s.so symlink then becomes essential. Incidentally, this is the
underlying reason why I believe the startfile_prefix_spec hack is a
bad solution.. but I'm not getting into that debate again :-)
3. Find some other solution. DIY currently does some funky stuff with
specs and -L/usr/lib and -B/usr/lib/, which works fine for standard
x86 builds but is untested (by me at least) for multilib builds and
may not work there.
BTW, DIY uses a much enhanced series of sanity checks in the toolchain
readjustemnt step which would have caught this flaw immediately. In view
of the current situation, LFS may want to adopt something similar.. tho'
the DIY sanity checks are geared towards scripting and rely upon the exit
status of `grep'. LFS would therefore need to adjust and/or word it
appropriately.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
