From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4511 Path: news.gmane.org!not-for-mail From: Gabriel Jacobo Newsgroups: gmane.linux.lib.musl.general Subject: Re: dlopen'ing glibc linked libraries Date: Tue, 21 Jan 2014 12:44:14 -0200 Message-ID: References: <52DE84BF.2090001@barfooze.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=485b3970d5a0cee3ab04f07c0a4a X-Trace: ger.gmane.org 1390315462 22310 80.91.229.3 (21 Jan 2014 14:44:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jan 2014 14:44:22 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4515-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 21 15:44:31 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1W5cZ1-0002QB-89 for gllmg-musl@plane.gmane.org; Tue, 21 Jan 2014 15:44:27 +0100 Original-Received: (qmail 23589 invoked by uid 550); 21 Jan 2014 14:44:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23581 invoked from network); 21 Jan 2014 14:44:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Gra6Um0lSCRW66UOyYcPFsRs5UVtWPL9OZLNGGAxMuk=; b=x4OOJjwHEStt8KFtpaA1shM3+JOdfiBw85cAD6hAZf8GP7RAbF6CEclGVqBo8xDD5+ GhzOnrpXuzMSxjD+2xHQF7Ci8U5iLwR8e+E8NCEAWj6b4Et2+ozc58AL/1mXXvm43v+b +RB/LPal18KWWfSDVM7ckO2v1SR21JkV4UCdVrHUzFspcDVlMbVpkurnLNTqjPp7mdrd 4JMn3609aNOMOINO4Kqnm5YpNWGlDUmQBTEQTRwoQcAqhN+3cKZvqE8hveIktv4NKDT1 OvB8J9tnsf6e6yUZVvcjZmi2qlbIsOkjwfLrquCkbbT2sM70MFyc1ozRWT+rQ/ZtRhB9 /7zw== X-Received: by 10.204.228.14 with SMTP id jc14mr106279bkb.175.1390315454771; Tue, 21 Jan 2014 06:44:14 -0800 (PST) In-Reply-To: <52DE84BF.2090001@barfooze.de> Xref: news.gmane.org gmane.linux.lib.musl.general:4511 Archived-At: --485b3970d5a0cee3ab04f07c0a4a Content-Type: text/plain; charset=ISO-8859-1 > > that's not quite true, sabotage linux builds mesa fine (with 2 minor > patches). > recipe: > https://github.com/sabotage-linux/sabotage/blob/master/pkg/mesalib#L19 > patches: > https://github.com/sabotage-linux/sabotage/blob/master/ > KEEP/mesalib-fpclassify.patch > https://github.com/sabotage-linux/sabotage/blob/master/ > KEEP/mesalib-strtod.patch > https://github.com/sabotage-linux/sabotage/blob/master/ > KEEP/mesalib-strtof.patch > > nothing actually works with the SDL/musl binary. >> > > basically what you should try to do is build all dependencies against musl. > > So, will it ever work? >> > > even if it would work, mixing glibc and musl linked things is far from > optimal. > > >> Thanks for the response. Let me express again that my experiment assumes there's binaries that you just can't rebuild against musl (nVidia binaries for example) or that's not practical to do so (like every binary provided by Ubuntu ;) ), and that's the fringe case that interests me the most right now. I would assume that if you rebuild all libraries against musl (or use SDL in a distro that's based on musl such as Sabotage), things would just work. But my question was oriented towards what's the goal for providing "full" binary compatibility with glibc. -- Gabriel. --485b3970d5a0cee3ab04f07c0a4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=

that's not quite true, sabotage linux builds mesa fine (with 2 minor pa= tches).
recipe:
https://github.com/sabotage-linux/sabotage= /blob/master/pkg/mesalib#L19
patches:
https://github.com/sabotage-= linux/sabotage/blob/master/KEEP/mesalib-fpclassify.patch
https://github.com/sabotage-linu= x/sabotage/blob/master/KEEP/mesalib-strtod.patch
https://github.com/sabotage-linu= x/sabotage/blob/master/KEEP/mesalib-strtof.patch

nothing actually works with the SDL/musl binary.

basically what you should try to do is build all dependencies against musl.=

So, will it ever work?

even if it would work, mixing glibc and musl linked things is far from opti= mal.



Thanks for the response. Let me express again that my experiment assu= mes there's binaries that you just can't rebuild against musl (nVid= ia binaries for example) or that's not practical to do so (like every b= inary provided by Ubuntu ;) ), and that's the fringe case that interest= s me the most right now.
I would assume that if you rebuild all libraries against musl (or use = SDL in a distro that's based on musl such as Sabotage), things would ju= st work. But my question was oriented towards what's the goal for provi= ding "full" binary compatibility with glibc.


--
Gabriel.
--485b3970d5a0cee3ab04f07c0a4a--