Date: Wed, 14 Aug 2013 10:27:10 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: problems with dynamic linking since 0.9.1 On Wed, Aug 14, 2013 at 11:06:29AM +0200, Jens wrote: > > >>>ld should be able to handle it (eg file libc.so, readelf -a > >>>libc.so, nm -D libc.so, or just ./libc.so) > >>> > >>>since you use landley's weird toolchain it may be a > >>>problem with the old binutils > >> > >>Thanks! You nailed it in one. If I use newer binutils it works. > >> > >>(In response to the wrapper problem, I let REALGCC point to the real > >>gcc and not the wrapper). > >> > >>Thanks again, > >>Jens > >> > >>> > >>>>bash-4.1# musl-gcc -c t.c > >>>>bash-4.1# musl-gcc t.o > >>>>/opt/musl/lib/libc.so: file not recognized: File format not recognized > >>>>collect2: ld returned 1 exit status > >>> > > > >It would be nice to get to the bottom of this, still. It's not my > >intent to require new binutils for linking against musl. Any idea why > >it might have been failing? Are there verbosity level options to ld > >that might help track this down? > > strace attached as trace.txt > > bash-4.1# strace -f -o /tmp/trace.txt musl-gcc t.o > /opt/musl/lib/libc.so: file not recognized: File format not recognized > collect2: ld returned 1 exit status > > verbose ld output attached as ld.txt > > bash-4.1# ld --verbose -dynamic-linker /lib/ld-musl-x86_64.so.1 > -nostdlib /opt/musl/lib/crt1.o /opt/musl/lib/crti.o > /usr/gcc/lib/crtbegin.o -L/opt/musl/lib -L /lib/. t.o > /usr/gcc/lib/libgcc.a /usr/gcc/lib/libgcc_eh.a -lc > /usr/gcc/lib/libgcc.a /usr/gcc/lib/libgcc_eh.a &> /tmp/ld.txt > > > > >By the way, how old were those binutils? I saw "firmware Linux" > >mentioned, which was the predecessor of Aboriginal, so unless that's > >just still landley's dir name, maybe these are a lot older than I > >thought.. > > bash-4.1# ld -V > GNU ld version 2.17 > Supported emulations: > elf_x86_64 > elf_i386 > i386linux > > Hope this helps. Thanks. I don't see anything obviously wrong in the trace or verbose output. Unless /lib is where you have musl installed (which doesn't seem to be the case, the -L /lib/. probably should not be there, but it doesn't seem related to the problem. Have you run the file command and/or readelf -a on libc.so as a sanity check? Perhaps something about the toolchain or existing wrapper messed up the link of libc.so. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.