From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3896 Path: news.gmane.org!not-for-mail From: Jens Newsgroups: gmane.linux.lib.musl.general Subject: Re: problems with dynamic linking since 0.9.1 Date: Wed, 14 Aug 2013 16:51:05 +0200 (CEST) Message-ID: References: <20130813110709.GH5368@port70.net> <20130813145259.GI5368@port70.net> <20130813180331.GE221@brightrain.aerifal.cx> <20130814142710.GN221@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Trace: ger.gmane.org 1376491804 14430 80.91.229.3 (14 Aug 2013 14:50:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Aug 2013 14:50:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3900-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 14 16:50:08 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1V9cOh-0006Cs-Fo for gllmg-musl@plane.gmane.org; Wed, 14 Aug 2013 16:50:03 +0200 Original-Received: (qmail 1979 invoked by uid 550); 14 Aug 2013 14:50:02 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1971 invoked from network); 14 Aug 2013 14:50:02 -0000 Received-SPF: none (smtp-gw11.han.skanova.net: domain laas.mine.nu does not designate permitted sender hosts) identity=mailfrom; receiver=smtp-gw11.han.skanova.net; client_ip=81.229.140.47; envelope-from=jensl@laas.mine.nu; helo=81-229-140-47-o1124.telia.com; In-Reply-To: <20130814142710.GN221@brightrain.aerifal.cx> User-Agent: Alpine 2.10 (LNX 1266 2009-07-14) Xref: news.gmane.org gmane.linux.lib.musl.general:3896 Archived-At: On Wed, 14 Aug 2013, Rich Felker wrote: > 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. bash-4.1# ls -l /lib/ld-musl-x86_64.so.1 lrwxrwxrwx 1 0 0 21 Aug 13 22:28 /lib/ld-musl-x86_64.so.1 -> /opt/musl/lib/libc.so bash-4.1# ls -l /opt/musl/lib/libc.so -rwxr-xr-x 1 0 0 2718991 Sep 23 2012 /opt/musl/lib/libc.so readelf -a /opt/musl/lib/libc.so outputs a _lot_ of stuff that I cannot interpret. bash-4.1# file /opt/musl/lib/libc.so /opt/musl/lib/libc.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped If I install newer binutils (musl + gcc is the same), the linking will succeed. Im happy that I have a workaround (or actually two, since I can link statically). Cheers, Jens > > Rich >