On Fri, Mar 21, 2008 at 1:04 PM, Oswin Krause <[EMAIL PROTECTED]> wrote: > hi all :) > Sorry, my English is a bit bad, i hope you understand me anyway :) > I'm currently working with the development version of LFS, because the > stable version didn't work for me. I got linker errors all the time when i > tried to compile the dummy.c. For getting the development tools to work, i > had to switch build order a bit, so i had to build the ld-new after i had > compiled the new glib.
First, don't change the build order, especially for the toolchain components. If you can't build ld-new following the bug, then that needs to be fixed. > gcc -O2 -pipe -DTCL_DBGX= -Wl,--export-dynamic tclAppInit.o > -L/mnt/lfs/sources/tcl8.4.18/unix -ltcl8.4 -ldl -lieee -lm \ > -Wl,-rpath,/tools/lib -o tclsh > /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' > collect2: ld returned 1 exit status > make: *** [tclsh] Error 1 > > > It seems that gcc chooses the wrong libc.6.so . I don't know how that can be > possible, the dummy.c was linked correctly: > > [EMAIL PROTECTED]:/mnt/lfs/sources$ /usr/bin/ldd a.out > libc.so.6 => /tools/lib/libc.so.6 (0x00002b609757a000) > /tools/lib/ld-linux-x86-64.so.2 (0x00002b609735e000) This is the difference between the build linker, ld, and the runtime linker, ld.so. When compiling, the ld that gcc is calling is not configured to search for libraries (libc.so in this case) in /tools/lib. It should be doing that after adjusting the toolchain to use ld-new. Your host's ldd is using the runtime linker, ld.so, and following the embedded RPATH (see -Wl,-rpath in the gcc command) to find /tools/lib/libc.so.6. You'll need to back up and figure out what the issue is with building ld-new. If you can't pass the sanity check after adjusting the toolchain, then there's no sense in continuing. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
