musl - How to deliver a portable shared object using musl

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Tue, 18 Jan 2022 15:28:54 +0530
From: Thejakiran katikala <katikalathejakiran@...ar.solutions>
To: musl@...ts.openwall.com
Cc: ashish <ashish@...ar.solutions>, manav <manav@...ar.solutions>
Subject: How to deliver a portable shared object using musl

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
Content of type "text/html" skipped

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.