[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220118151131.GF7074@brightrain.aerifal.cx>
Date: Tue, 18 Jan 2022 10:11:33 -0500
From: Rich Felker <dalias@...c.org>
To: Thejakiran katikala <katikalathejakiran@...ar.solutions>
Cc: musl@...ts.openwall.com, ashish <ashish@...ar.solutions>,
manav <manav@...ar.solutions>
Subject: Re: How to deliver a portable shared object using musl
On Tue, Jan 18, 2022 at 03:28:54PM +0530, Thejakiran katikala wrote:
> Hi Team,
>
> I know that using musl-libc I can deliver a portable executable.
> Extending this concept, I am trying to deliver a portable shared
> object across various linux distros and architectures. I essentially
> want to reduce the number of combinations I currently have to deal
> with, e.g.:
>
> Mylib.so linked against glibC across ARM and x86 architectures
>
> Mylib.so linked against musl-libc across ARM and x86 architectures
>
> Mylib.so linked against uClibC across ARM and x86 architectures
>
> To reduce the number of deliverables, I wanted to squash musl-libC
> into Mylib.so and suppress all the conflicting symbols with
> glibc/uClibC, etc..
>
> So conceptually MyLib.so carries a copy of musl-libC such that I
> don't have any external dependencies on the system where a 3rd party
> developer could write his application on top of my library.
>
> For e.g. he could create an executable by compiling and linking on
> Ubuntu x64_64: main.c + MyLib.so.x86_64 + glibC.so.x86_64
>
> Is the above possible? Can MyLib.so.x86_64 with musl-libc squashed
> into it with all symbols suppressed to avoid linker conflicts, work
> in a program that also links to glibC? Can musl-libc co-exist with
> glibC OR would there be some run-time conflicts around
> threads/malloc, etc.?
That is not possible. You can't have multiple libcs living in the same
process. Even if you could get rid of the symbol clashes, in general
these functions may depend on global state that won't be initialized
-- or process state managed by the kernel such as the thread pointer,
exit futex addresses, etc. -- that will not match what the other libc
setup.
If you just need "pure library code" like string.h functions, math
functions, etc. then this code can in theory be extracted out of musl
and used independently. Basically, if you can compile it using only
the public musl headers it's safe to use, but if it requires any
internal headers to build, you'd have to check and clean that up. In
particular, anything using syscalls or thread-local storage (including
access to errno) can't be used this way without some adaptation.
A derivative work of musl aimed at the usage case you're talking about
(working safely alongside a host libc, with functionality constrained
by that requirement) would be an interesting project, but outside the
scope of what's being maintained as musl.
Rich
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.
