Date: Fri, 26 Jun 2020 12:35:02 -0400 From: Rich Felker <dalias@...c.org> To: Gregory Heytings <ghe@....org> Cc: musl@...ts.openwall.com Subject: Re: Using only a portion of 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.
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.