[musl] How to deliver a portable shared object using musl

[musl] How to deliver a portable shared object using musl

[Thejakiran katikala]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

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.?

Is there anyway to achieve the above? Appreciate your insights.

Note: i would like to be Cc'd to receive back your replies

Thanks,

-Theja

[-- Attachment #2: Type: text/html, Size: 1849 bytes --]

Re: [musl] How to deliver a portable shared object using musl

[Rich Felker]

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