[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHGmiitQhmMJQMXQCV_yt6gw7r85PCQkQcxM79r0kVmCwE6VTA@mail.gmail.com>
Date: Wed, 12 Nov 2025 19:26:17 +0100
From: Fredrik Orderud <forderud@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Safe to load musl shared lib into glibc executable?
On Wed, Nov 12, 2025 at 3:47 PM Rich Felker <dalias@...c.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
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.
