[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Jan 2014 17:28:35 +0100
From: John Spencer <maillist-musl@...fooze.de>
To: musl@...ts.openwall.com
Subject: Re: dlopen'ing glibc linked libraries
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.
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.
