Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Jan 2014 17:28:35 +0100
From: John Spencer <>
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:
>> patches:
>> KEEP/mesalib-fpclassify.patch
>> KEEP/mesalib-strtod.patch
>> 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.


> 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:;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.