From: John Spencer <maillist-musl@barfooze.de>
To: musl@lists.openwall.com
Subject: Re: dlopen'ing glibc linked libraries
Date: Tue, 21 Jan 2014 17:28:35 +0100 [thread overview]
Message-ID: <52DEA033.7090605@barfooze.de> (raw)
In-Reply-To: <CAKDfeskchVQzrQF7HZKydJMT+yyaSmVGmRebpny-GnTebrRQ4g@mail.gmail.com>
Gabriel Jacobo wrote:
>> 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.
OK, but in that case it's much saner if everything else is compiled
against musl, and the nvidia binary the only impurity.
more binaries == more crazy glibc apis that could be willingly or
unwillingy getting pulled in
> 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.
correct.
> But my question was oriented towards what's the goal for providing "full"
> binary compatibility with glibc.
i dont think we'll ever have 100% compatibility, since there are a lot
of situations where the interfaces implemented by GLIBC are, to a
varying degree, non-conformant, so things could fail at runtime:
if software uses crazy glibc extensions in printf format specifiers:
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=1d3f7975f920f47e6a8a324f547da2180e64171a
or the pthread stack size issue (SDL bug mentioned earlier).
there's also strerror_r, for which the default symbol uses the broken
glibc semantics, whereas the POSIX-conformant version is called
__xpg_strerror_r in glibc (users of strerror_r get redirected there,
unless they #define _GNU_SOURCE)...
additionally there are some interfaces like qsort_r where different
implementations exist (the earlier BSD version and the GNU version have
the argument order swapped), so implementing one of the 2 versions in
musl could lead to silent breakage when a configure check tests for
qsort_r, finds and uses it, but assumes different behaviour.
lastly, glibc tends to pull in a lot of implementation-internal __
prefixed functions, for example when some macros like _FORTIFY_SOURCE
are defined.
so in order to be 100% compatible, we'd have to turn musl into a full
glibc clone, with all of its bugs, bloat, (mis)features, and throw POSIX
conformance over board.
however we're constantly adding legacy APIs that we see in usage, if
they're not extremely ugly or intrusive, so the compatibility improves
with every release.
so it's well possible that the compatibility is good enough for a single
piece of sw, like nvidia drivers, but not for some other libraries it
wants to link against. in that case it's safe to hand it musl-linked
versions of those libraries instead.
next prev parent reply other threads:[~2014-01-21 16:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-21 13:57 Gabriel Jacobo
2014-01-21 14:31 ` John Spencer
2014-01-21 14:44 ` Gabriel Jacobo
2014-01-21 16:28 ` John Spencer [this message]
2014-01-21 18:17 ` Szabolcs Nagy
2014-01-23 10:07 ` Szabolcs Nagy
2014-01-24 10:07 ` Justin Cormack
2014-01-24 13:41 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52DEA033.7090605@barfooze.de \
--to=maillist-musl@barfooze.de \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).