[musl] Safe to load musl shared lib into glibc executable?

[musl] Safe to load musl shared lib into glibc executable?

[Fredrik Orderud]

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.

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.

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?

Any advise on the safety of loading a musl shared lib into glibc
executable? Any limitations or expected problems to watch out for?

Thanks in advance,
Fredrik Orderud

Re: [musl] Safe to load musl shared lib into glibc executable?

[Rich Felker]

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

Re: [musl] Safe to load musl shared lib into glibc executable?

[Fredrik Orderud]

On Wed, Nov 12, 2025 at 3:47 PM Rich Felker <dalias@libc.org> wrote:
> If you're making a shared library, you cannot static link libc into
> it. This is breaking whether you are using glibc or musl.

Thanks a lot for quick and clear answers, Rich! I'll then continue
with my current approach of linking to an old version of glibc when
building the shared lib. in question.

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

My background is mostly from Windows where it's always been simple to
link statically to the C library when building a shared library. The
glibc and musl limitations in this area therefore came as a surprise
to me. Do you think it could be possible to update the musl
documentation  to more explicitly mention this limitation, so that
this is clear for the next developer down the road?

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

It would also be nice with some more documentation on interoperability
limitations when loading a dynamically musl-linked library into a
glibc process and vice versa, since I might be facing these use-cases
in the future.

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

Not what I was hoping for, but I can live with that. Thanks anyhow for
the clear answers.

Fredrik

Re: [musl] Safe to load musl shared lib into glibc executable?

[Thorsten Glaser]

Fredrik Orderud dixit:

>My background is mostly from Windows where it's always been simple to
>link statically to the C library when building a shared library. The
>glibc and musl limitations in this area therefore came as a surprise

As a Unix user it’s less surprising. I can only assume that on
Windows, the “libc” does much less and that the various Win32
DLLs you’re also implicitly linking against do the shared state
parts.

There exist projects that embed a musl subset running on the
host libc (though for the one I have in mind that’s also a musl),
you’d have to do lots of work for that though. First, identify
what actual functions you need…

Other projects get around this problem by expecting the caller
to provide all necessary functions (and link with -Bsymbolic)
and not using any libc headers themselves. This would work like:


/* yourlib/extapi.h */

int yourlib_printf(const char *, ...);


/* yourlib/impl.c */

void foo() {
	yourlib_printf("Hi!\n");
}


/* user/yourlib_glue.c */

#include <stdarg.h>
#include <stdio.h>
#include <yourlib/extapi.h>

int yourlib_printf(const char *msg, ...) {
	int rv;
	va_list ap;

	va_start(ap, msg);
	rv = vfprintf(stdout, msg, ap);
	va_end(ap);
	return (rv);
}


So basically, you put the binding of the libc functions
into the user’s responsibility.

You could even ship such a file.

Or just ship your library as source and expect users to
build it for their local systems, if that’s possible.

Good luck,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
	-- Tonnerre Lombard in #nosec

Re: [musl] Safe to load musl shared lib into glibc executable?

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 1871 bytes --]

On 11/12/25 13:26, Fredrik Orderud wrote:
> On Wed, Nov 12, 2025 at 3:47 PM Rich Felker <dalias@libc.org> wrote:
>> If you're making a shared library, you cannot static link libc into
>> it. This is breaking whether you are using glibc or musl.
> 
> Thanks a lot for quick and clear answers, Rich! I'll then continue
> with my current approach of linking to an old version of glibc when
> building the shared lib. in question.
> 
>> 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.
> 
> My background is mostly from Windows where it's always been simple to
> link statically to the C library when building a shared library. The
> glibc and musl limitations in this area therefore came as a surprise
> to me. Do you think it could be possible to update the musl
> documentation  to more explicitly mention this limitation, so that
> this is clear for the next developer down the road?

This is one of the factors.  The other is that Windows supports
two-stage symbol lookup, meaning that symbol X in your DLL can be
different than symbol X in a different DLL or the main executable.
This is a huge advantage for shipping stuff in binary form.

It would also be useful for musl to implement this, but I'm not going
to ask for it because I don't have the time to send a patch right now.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [musl] Safe to load musl shared lib into glibc executable?

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 2559 bytes --]

On 11/12/25 13:50, Thorsten Glaser wrote:
> Fredrik Orderud dixit:
> 
>> My background is mostly from Windows where it's always been simple to
>> link statically to the C library when building a shared library. The
>> glibc and musl limitations in this area therefore came as a surprise
> 
> As a Unix user it’s less surprising. I can only assume that on
> Windows, the “libc” does much less and that the various Win32
> DLLs you’re also implicitly linking against do the shared state
> parts.

Exactly!

> There exist projects that embed a musl subset running on the
> host libc (though for the one I have in mind that’s also a musl),
> you’d have to do lots of work for that though. First, identify
> what actual functions you need…
> 
> Other projects get around this problem by expecting the caller
> to provide all necessary functions (and link with -Bsymbolic)
> and not using any libc headers themselves. This would work like:
> 
> 
> /* yourlib/extapi.h */
> 
> int yourlib_printf(const char *, ...);
> 
> 
> /* yourlib/impl.c */
> 
> void foo() {
> 	yourlib_printf("Hi!\n");
> }
> 
> 
> /* user/yourlib_glue.c */
> 
> #include <stdarg.h>
> #include <stdio.h>
> #include <yourlib/extapi.h>
> 
> int yourlib_printf(const char *msg, ...) {
> 	int rv;
> 	va_list ap;
> 
> 	va_start(ap, msg);
> 	rv = vfprintf(stdout, msg, ap);
> 	va_end(ap);
> 	return (rv);
> }
> 
> 
> So basically, you put the binding of the libc functions
> into the user’s responsibility.
> 
> You could even ship such a file.
> 
> Or just ship your library as source and expect users to
> build it for their local systems, if that’s possible.

This is what I recommend if possible.  It makes it much easier for
users to debug problems.  It makes it easier to use your library with
build systems that prefer to build stuff from source.  And it avoids
ABI stability issues.

With the exception of distro packages, the Linux ecosystem seems to be
generally designed around this.  Most tooling I know of assumes that
third-party libraries are either built from source, are provided by the
distribution, or are at least built against the distribution's libc.
From what I have seen, third-party binary-only libraries are generally
somewhat of an afterthought, if they are supported at all.

Providing your library as source code doesn't mean it needs to be
open-source.  It's perfectly feasible to ship source code under a
proprietary license.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [musl] Safe to load musl shared lib into glibc executable?

[Carlos O'Donell]

On 11/12/25 9:47 AM, Rich Felker wrote:
> 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.
I agree that this isn't a "musl" problem, but rather a general toolchain
question.

You need a curated sysroot and you need your tools configured to use
that sysroot if you have these specific needs.

-- 
Cheers,
Carlos