mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] How to deliver a portable shared object using musl
@ 2022-01-18  9:58 Thejakiran katikala
  2022-01-18 15:11 ` Rich Felker
  0 siblings, 1 reply; 2+ messages in thread
From: Thejakiran katikala @ 2022-01-18  9:58 UTC (permalink / raw)
  To: musl; +Cc: ashish, manav

[-- 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 --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [musl] How to deliver a portable shared object using musl
  2022-01-18  9:58 [musl] How to deliver a portable shared object using musl Thejakiran katikala
@ 2022-01-18 15:11 ` Rich Felker
  0 siblings, 0 replies; 2+ messages in thread
From: Rich Felker @ 2022-01-18 15:11 UTC (permalink / raw)
  To: Thejakiran katikala; +Cc: musl, ashish, manav

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-01-18 15:11 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-18  9:58 [musl] How to deliver a portable shared object using musl Thejakiran katikala
2022-01-18 15:11 ` Rich Felker

Code repositories for project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).