[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a89d65c8-5d97-4c8c-9260-78b6115c7ccf@gmail.com>
Date: Wed, 12 Nov 2025 14:30:18 -0500
From: Demi Marie Obenour <demiobenour@...il.com>
To: musl@...ts.openwall.com, Thorsten Glaser <tg@...bsd.de>,
Fredrik Orderud <forderud@...il.com>
Subject: Re: Safe to load musl shared lib into glibc executable?
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)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
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.
