[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.10.1308141641390.10050@laas.mine.nu>
Date: Wed, 14 Aug 2013 16:51:05 +0200 (CEST)
From: Jens <jensl@...s.mine.nu>
To: musl@...ts.openwall.com
Subject: Re: problems with dynamic linking since 0.9.1
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
>
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.
