* Re: [musl] Using only a portion of musl?
2020-06-26 13:51 [musl] Using only a portion of musl? Gregory Heytings
@ 2020-06-26 16:35 ` Rich Felker
0 siblings, 0 replies; 2+ messages in thread
From: Rich Felker @ 2020-06-26 16:35 UTC (permalink / raw)
To: Gregory Heytings; +Cc: musl
On Fri, Jun 26, 2020 at 01:51:33PM +0000, Gregory Heytings wrote:
>
> Hi list,
>
> Are the parts of the musl library independent, or do they depend on
> each other? In other words, is it possible to use only a part of
> the musl library in a program, and to use the host libc for
This should be documented a lot better and perhaps formalized in the
structure of the source tree. In short yes, some parts are
independent, just not documented as such. I'll give a rough sketch of
such documentation here:
Generally, we aim to keep implementations of nonstandard extensions
which *can* be implemented portably on top of standard interfaces
(note: some can't and inherently interact with internals) entirely
non-musl-specific. This is also true, or at least mostly true, of some
standard interfaces. Some things that come to mind beyond the ones you
asked about:
- glob
- qsort
- bsearch
- tsearch
- string functions
- multibyte
- gettext
- iconv
- ctype
- crypt
- math functions (including complex)
In some of these you may find minor tie-in to musl like use of LOCK
macro or weak_alias macro, __-prefixed symbol names to protect
namespace, etc., but at least logically they're independent.
> everything else? For example, is it possible to use the "regex",
> the "thread", the "malloc", the "network", ... parts of musl in a
> program, independenly of the rest of musl?
Thread, absolutely not. The threads implementation is the most "core"
part of a libc there is. Early implementations treating it as an
add-on component (LinuxThreads, similar on proprietary unices) were
badly wrong and fundamentally couldn't work right. It has to be tied
into dynamic linking, access to thread-local memory, internal locking
in interfaces that need to be thread-safe, behavior of locks left
locked when a thread exits, cancellable functions, emulating
process-wide properties where the kernel only gives you thread-local
ones (note: this one is a Linux-specific issue due to kernel doing
stuff wrong), fork, etc. Some of the cross-deps could be reduced at
the cost of less over-linking static programs and hurting performance
in single-threaded programs, but most are fundamental.
Thread synchronization primitives, on the other hand, *kinda* can be
use independently, at least in theory. There's no fundamental reason
you can't use locks different from the ones the implementation
provides. However, in practice most of the standard mutex, etc.
implementations need to link into the core of the threads
implementation for various reasons. For example mutexes need to link
into the robust list for robust-mutex support. But if you took musl's
mutex implementation and ripped out support for things that have to
tie into the threads implementation core, you'd get "portable" (to any
target with futex) code.
Now, on to other things:
Regex: mostly yes. At worst it has some __-prefixed symbols that can't
be used (portably) outside libc.
Malloc: don't use oldmalloc. It's deprecated. In theory it could be
adapted for use outside musl without much work but it's not a good
idea. The new malloc is already available for use outside musl:
https://github.com/richfelker/mallocng-draft
Network: In general, nope. These are tie-ins with particular
implementation choices including struct ABI, syscall linkage, etc.,
and in particular working around ways the raw Linux interfaces are
non-POSIX-conforming. But there are some exceptions:
- getaddrinfo & its dependencies: mostly portable, modulo __ issues.
- dn_*, dns_*, and res_*: same
- getifaddrs, if_nameindex: these are Linux-netlink specific but
otherwise should not be tied tightly into musl.
^ permalink raw reply [flat|nested] 2+ messages in thread