Re: problems with dynamic linking since 0.9.1

[Jens <jensl@laas.mine.nu>]

On Wed, 14 Aug 2013, Rich Felker wrote:

> On Wed, Aug 14, 2013 at 04:49:55PM +0200, Szabolcs Nagy wrote:
>> * Rich Felker <dalias@aerifal.cx> [2013-08-14 10:27:10 -0400]:
>>> On Wed, Aug 14, 2013 at 11:06:29AM +0200, Jens wrote:
>>>> 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.
>>>
>>
>> wasn't there an issue that the last gplv2 binutils version
>> failed to produce a working libc.so with -Bsymbolic-functions?
>
> My recollection was that it failed to support -Bsymbolic-functions at
> all and would produce an error when encountering it, so this makes me
> wonder how generation of libc.so succeeded at all...

The musl libc in this case is built with binutils-2.20.1, since the older 
binutils (2.17) didnt work. You helped me with this exact problem some 
months ago.

I have a build-environment where I specify all the dependencies for each 
build. binutils-2.20.1 is then a dependency for musl (where binutils 2.17 
is the default).

So for my use-case I can always specify a later binutils as a dependency 
for all musl builds. Though dynamic linking is a low priority for me, 
since all resulting binaries must be statically linked.

Regards,
Jens

>
> Rich
>