[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251112144730.GI1827@brightrain.aerifal.cx>
Date: Wed, 12 Nov 2025 09:47:31 -0500
From: Rich Felker <dalias@...c.org>
To: Fredrik Orderud <forderud@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Safe to load musl shared lib into glibc executable?
On Wed, Nov 12, 2025 at 03:33:42PM +0100, Fredrik Orderud wrote:
> I'm working on a project developing a Linux shared library (.so) that
> we want to be as widely compatible as possible with multiple distros
> of various age. Glibc have already caused compatibility problems for
> deployment systems older than the build system. I'm therefore
> investigating if musl could be an alternative, since it supports
> static linking to the C library.
If you're making a shared library, you cannot static link libc into
it. This is breaking whether you are using glibc or musl.
> We're unable to require all library users to also switch to musl.
> Therefore, for musl to be an alternative to glibc, then it must be
> possible load a shared lib compiled with musl into executables still
> compiled with glibc. Our library API doesn't transfer ownership of any
> malloc/free pointers or similar, so it should in principle be
> compatible with using a different C library internally vs. in the
> client code.
The problem is that, even if you could embed your own libc instance
into your library, it will assume it has ownership of process-wide
singletons that the "real" host libc the rest of the program is using
also assumes it has ownership over. Things like the thread pointer
register, signal disposition, heap brk point, etc.
In principle one could make a libc that's designed to be hosted by
something external to itself, with functionality limited to what it
could do without owning process state, but that is not what musl is.
> I've already managed to load shared lib compiled with musl into
> executables compiled with glibc in a tiny test project if adding musl
> to LD_LIBRARY_PATH before starting the executable. However, the musl
> FAQ mentions that "Binary compatibility is much more limited". I'm
> therefore unsure if it's in general safe to mix musl with glibx this
> way in the same process?
The binary compatibility being referred to is about loading a
dynamically glibc-linked library into a musl process (or vice versa,
but the other direction is less likely to work). It's not about
statically linking libc into another shared library, which is never
supported.
> Any advise on the safety of loading a musl shared lib into glibc
> executable? Any limitations or expected problems to watch out for?
You probably need to be doing what most folks doing this with glibc
hosts do, and linking your library dynamically against an ancient
version of glibc to avoid pulling in versioned symbol deps on newer
versions. This also requires committing to supporting whatever bugs
the old versions of the affected interfaces might have. Unfortunately
I don't think there's a way musl can help make this situation any
better.
Rich
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.
