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