[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+jXYnQrrvBFG1i9wkjn3_cQwdLN=HAWpO45B8YOvk4OPuEBvA@mail.gmail.com>
Date: Thu, 14 Jul 2016 11:17:27 +0100
From: Aidan Hobson Sayers <aidanphs@...il.com>
To: musl@...ts.openwall.com
Cc: Jason Ramapuram <jason.ramapuram@...il.com>
Subject: Re: Regarding whole-archive linking libc.a into a shared lib
There's a brief coverage of some of the problems with this idea in
http://www.openwall.com/lists/musl/2012/12/08/4
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" <jason.ramapuram@...il.com>
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 (
> http://stackoverflow.com/questions/38251344/musl-fails-to-link-libc-a-into-shared-library)
> 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/mylib.so: 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/mylib.so’ failed
> make: *** [tgt/Linux-x86_64/mylib/lib/mylib.so] Error 1
>
> I understand this might conflict when someone tries to link against this
> and libc.so 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.
