Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Jul 2016 12:49:31 +0200
From: Jason Ramapuram <>
To: Aidan Hobson Sayers <>
Subject: Re: Regarding whole-archive linking libc.a into a shared lib

Thanks for the link. Just went through the entire thread. I think we can
solve the problems as such though:

   1. Have some form of linker that mangles all the symbols internally in
   the newly linked shared library, eg: FILE* --> FILE_mangled* so that
   internally it has it's own libc calls that are independent from anything
   that a binary might require.
   2. Block allocate a chunk of memory internally in the library so that
   allocations are now using that internal block and not malloc-ing.

However, I'm not quite sure how 1) could be solved at this time.

On Thu, Jul 14, 2016 at 12:17 PM, Aidan Hobson Sayers <>

> There's a brief coverage of some of the problems with this idea in
> The relevant part is this bit: "But now you're potentially using two
> different versions of libc in the same program; if implementation-internal
> data structures like FILE or the pthread structure are not identical
> between the 2 versions, you'll hit an ABI incompatibility, despite the fact
> that these data structures were intended to be implementation-internal and
> never affect ABI. Even without that issue, you have issues like potentially
> 2 copies of malloc trying to manage the heap without being aware of one
> another, and thus clobbering it."
> It's worth reading the whole thread as there a couple of other directly
> relevant bits. I've wanted to do the same as you in the past, but the
> number of possible (/probable) issues was quite discouraging.
> On 14 Jul 2016 11:04 am, "Jason Ramapuram" <>
> wrote:
>> Hello there,
>> Is it at all possible to link musl's libc.a statically into a shared lib?
>> After a lot of trying I either get relocation errors (when using musl-gcc
>> built on say centos7) as such (
>> or hidden symbols not being defined like below (when using Alpine linux) :
>> /home/buildozer/aports/main/musll/src/musl-1.1.12/src/ldso/x86_64/tlsdesc.s:36:
>> undefined reference to `__tls_get_new'
>> /usr/lib/gcc/x86_64-alpine-linux-musl/5.3.0/../../../../x86_64-alpine-linux-musl/bin/ld:
>> tgt/Linux-x86_64/mylib/lib/ hidden symbol `__tls_get_new’ isn't
>> defined
>> /usr/lib/gcc/x86_64-alpine-linux-musl/5.3.0/../../../../x86_64-alpine-linux-musl/bin/ld:
>> final link failed: Bad value
>> collect2: error: ld returned 1 exit status
>> Makefile:58: recipe for target ‘tgt/Linux-x86_64/mulib/lib/’
>> failed
>> make: *** [tgt/Linux-x86_64/mylib/lib/] Error 1
>> I understand this might conflict when someone tries to link against this
>> and from a binary, however would it be possible somehow to mangle
>> all the libc calls internally inside the shared lib? Is there a tool that
>> would be able to do this? It would be really nice to have a portable shared
>> lib that has libc built in.

Content of type "text/html" skipped

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.