[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140121181726.GL1685@port70.net>
Date: Tue, 21 Jan 2014 19:17:27 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: dlopen'ing glibc linked libraries
* Gabriel Jacobo <gabomdq@...il.com> [2014-01-21 12:44:14 -0200]:
> But my question was oriented towards what's the goal for providing "full"
> binary compatibility with glibc.
no, full bug compatibility is not a goal (that would defeat the
purpose of a new libc)
that said, most apis are binary compatible with glibc (even for c++)
if you see a missing symbol or other breakage then please report it
here is a list of known issues:
http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc
it may be possible to solve a lot of compatibility issues with
preloading an extra lib next to musl, i experimented with running
applications with
export LD_LIBRARY_PATH=/usr/lib:/usr/lib/i386-linux-gnu:/lib/i386-linux-gnu
export LD_PRELOAD=./libcompat.so
/lib/ld-musl-i386.so /usr/bin/something
on a debian system and a lot of things work (except the loader
crashes occasionally due to a kernel bug..)
(for instance glibc linked libstdc++ works easily or i can compile
with a glibc linked gcc loaded by musl)
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.
