Sanity check output from 6.12 GCC is identical to output from 6.10 Toolchain

Dan Nicholson dbn.lists at gmail.com
Sun Feb 25 16:39:25 PST 2007


On 2/25/07, Alex Winfield <lordadonis at gmail.com> wrote:
>
> >so it seems like the environment is set up correctly.
> >But the system is still using the old linker.
> >
> >from your original message:
> >root:/sources# grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
> >SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
> >
> >at this point it may be good to back up to ch 6.11 and reinstall binutils.
> >then if you still get /tools in the output of ch 6.12, you might have to
> >restart ch 6 all over again.

That's not gonna help. We already saw that the output from /usr/bin/ld
that the new linker is doing the right thing. The problem is that gcc
was using the /tools linker for some reason. You can see what gcc is
gonna use with this command:

$ gcc -print-prog-name=ld

> I tried the reinstall of binutils, with the same output.
> After restarting ch. 6, I got the correct search_dir's, but still the
> wrong startfiles.
>
> root:/sources/gcc-build# echo 'main(){}' > dummy.c
> root:/sources/gcc-build# cc dummy.c -Wl,--verbose &> dummy.log
> root:/sources/gcc-build# readelf -l a.out | grep ': /lib'
>       [Requesting program interpreter: /lib/ld- linux.so.2]
> root:/sources/gcc-build# grep -o '/usr/lib.*/crt[1in].* .*' dummy.log
> /usr/lib/crt1.o succeeded
> /usr/lib/crti.o succeeded
> /usr/lib/crtn.o succeeded
> root:/sources/gcc-build# grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
> SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
> SEARCH_DIR("/usr/local/lib")
> SEARCH_DIR("/lib")
> SEARCH_DIR("/usr/lib");
> root:/sources/gcc-build# grep "/lib/libc.so.6 " dummy.log
> attempt to open /lib/libc.so.6 succeeded
> root:/sources/gcc-build# grep found dummy.log
> found ld-linux.so.2 at /lib/ld-linux.so.2
>
> But isn't /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crt1.o the same
> as /usr/lib/crt1.o because of the elipses?

What's wrong here? Everything seems correct to me.

--
Dan



More information about the lfs-support mailing list