Add initial support for the MUSL C library.


Add initial support for the MUSL C library.

This patch adds the LIBCXX_LIBC_IS_MUSL cmake option to allow the
building of libcxx with the Musl C library. The option is necessary as
Musl does not provide any predefined macro in order to test for its
presence, like GLIBC. Most of the changes specify the correct path to
choose through the various #if/#else constructs in the locale code.

Depends on D13407.

Reviewers: mclow.lists, jroelofs, EricWF

Subscribers: jfb, tberghammer, danalbert, srhines, cfe-commits

Differential Revision:


vkalintirisNov 9 2015, 2:21 AM
Differential Revision
D13673: Add initial support for the MUSL C library.
rL252456: Merging r249165:
dalias added a subscriber: dalias.EditedNov 16 2015, 7:59 PM

I realize your build system might not be setup to deal with this situation any better, so if so, I apologize in advance for the noise. Much of this patch, however, is exactly the reason why musl does not provide a __MUSL__ macro (see the musl FAQ): in short, these hard-coded assumptions about what functions musl does not have will break the build if/when musl adds them. The right way, from our perspective, to do this would be with build-time detection for nonstandard functions like strtoll_l. By unconditionally defining them as static-inline when targeting musl, the build will break if musl's locale.h ever adds a declaration for an extern version.

Some other things are also wrong. The __ctype_b_loc function in musl is not API but rather minimal ABI compat for running some glibc-linked binaries. This probably does not matter, but the only public locale API in musl is the standard functions. There are no exported character type tables, and musl does not even use such tables internally. If you really insist on having tables, the right behavior is to build them at runtime from the standard functions' return values, but simply calling the functions is always going to be lighter and faster than using tables here.

quick_exit and C11 functions should probably also be detected, but since we already have them in musl it's unlikely to hurt to assume they exist.

Hi Rich,

Thanks you for your comments. I'll try to fix the issue with the character type tables in a follow-up commit.

Initially, I did exactly what you described, ie. use CMake's check_function_exists() to test for the existence/lack of non-standard functions. However, in the end, I opted for the simpler solution of allowing the user to specify whether the C library being used is Musl. Otherwise, we would have to add tests for every single function in xlocale.h (there's almost 40 of them) and wrap each one of them in #ifdefs.

My goal while writing this patch, was to reach a point where I could build libcxx with Musl and pass the LLVM test-suite successfully. I'll keep on working on this once I figure out a few other issues that I have to solve in order to run the libcxx tests.

Are you sure you'd have to wrap all of them? Most of the "xlocale" functions are just standard functions that are in locale.h since POSIX 2008. Only a few are nonstandard. Of course from a practical standpoint it should work to start out just testing the ones you've observed missing on some systems, then add more later as needed.