Date: Thu, 14 Jul 2016 12:49:31 +0200 From: Jason Ramapuram <jason.ramapuram@...il.com> To: Aidan Hobson Sayers <aidanphs@...il.com> Cc: musl@...ts.openwall.com 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 <aidanphs@...il.com> wrote: > 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.