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.