>>> 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.

Cheers,
Jens

>
> Rich
>