[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <649a02c95992ea76251370ceeaa3a1cb@elear.solutions>
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
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.
