From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2027 invoked from network); 18 Jan 2022 11:49:25 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Jan 2022 11:49:25 -0000 Received: (qmail 23873 invoked by uid 550); 18 Jan 2022 11:49:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3722 invoked from network); 18 Jan 2022 09:59:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elear.solutions; s=20150816; t=1642499934; bh=UnQ3+q03m6rIKUO0iWwzrk+M5c3InwC/NdMBDMdDl4k=; h=Date:From:To:Cc:Subject; b=OPmbDe7tKxV7IaXdIFcfLXCszjAG6VM1xMytXtlDqf20Q7aid5WSlxZ6j65OBCZLS oUhI+3YkTeDhT8JiddsFPwJr8Ed2Lan9pBdTNDRyh9j8nM9olmb7j7T8mNHjR82tAL 4K3h7Oc3aSsiTKX15ujPX1H8HvfJlgJsoGXG8fxw= MIME-Version: 1.0 Date: Tue, 18 Jan 2022 15:28:54 +0530 From: Thejakiran katikala To: musl@lists.openwall.com Cc: ashish , manav User-Agent: Roundcube Webmail/1.4.8 Message-ID: <649a02c95992ea76251370ceeaa3a1cb@elear.solutions> X-Sender: katikalathejakiran@elear.solutions X-Priority: 1 (Highest) Content-Type: multipart/alternative; boundary="=_50d600acef1d4301864270385d8006ea" X-CMAE-Score: 0 X-CMAE-Analysis: v=2.4 cv=f50ruM+M c=1 sm=1 tr=0 ts=61e68f5e a=tP37S3kziUTlsvf/OIMBJg==:117 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=QwFk_PaVOhMA:10 a=ZZnuYtJkoWoA:10 a=cxsvBXmAjdhEOq0axDYA:9 a=CjuIK1q_8ugA:10 a=-u04jlg5jey5HksT3vQA:9 a=DPFpNN5FmNEUhoW9:21 a=_W_S_7VecoQA:10 a=QEXdDO2ut3YA:10 Subject: [musl] How to deliver a portable shared object using musl --=_50d600acef1d4301864270385d8006ea Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed 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 --=_50d600acef1d4301864270385d8006ea Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Team,

I know that using musl-libc I can deliver a portable ex= ecutable. Extending this concept, I am trying to deliver a portable shared = object across various linux distros and architectures. I essentially want t= o 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 architectur= es

Mylib.so linked against uClibC across ARM and x86 architectures<= /strong>


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.= =2E


So conceptually MyLib.so carries a copy of musl-libC such that I don't h= ave any external dependencies on the system where a 3rd party de= veloper could write his application on top of my library.


For e.g. he could create an executable by compiling and linking on Ubunt= u 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 repl= ies

Thanks,

-Theja



--=_50d600acef1d4301864270385d8006ea-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25356 invoked from network); 18 Jan 2022 15:11:49 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Jan 2022 15:11:49 -0000 Received: (qmail 11338 invoked by uid 550); 18 Jan 2022 15:11:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 11303 invoked from network); 18 Jan 2022 15:11:45 -0000 Date: Tue, 18 Jan 2022 10:11:33 -0500 From: Rich Felker To: Thejakiran katikala Cc: musl@lists.openwall.com, ashish , manav Message-ID: <20220118151131.GF7074@brightrain.aerifal.cx> References: <649a02c95992ea76251370ceeaa3a1cb@elear.solutions> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <649a02c95992ea76251370ceeaa3a1cb@elear.solutions> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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