FAQ

Q: lib(m|pthread|crypt).a/so are empty?

Yes, this is by design. musl puts everything into libc.a/so to avoid memory bloat. The empty files are only there for compatibility reasons. The official explanation: http://openwall.com/lists/musl/2012/07/25/3 more info: Design Concepts

Q: Why is there no __MUSL__ macro?

It’s a bug to assume a certain implementation has particular properties rather than testing. So far, every time somebody’s asked for this with a particular usage case in mind, the usage case was badly wrong, and would have broken support for the next release of musl. The official explanation: http://openwall.com/lists/musl/2013/03/29/13

Q: Where is ldd?

musl’s dynamic linker comes with ldd functionality built in. Just create a symlink from ld-musl-$ARCH.so to /bin/ldd. If the dynamic linker was started as “ldd”, it will detect that and print the appropriate DSO information.

Q: Why is sys/queue.h not included?

sys/queue.h is a full library implemented in a header file, and there’s no reason for it to be part of libc; the file is completely self-contained and independent. musl aims not to have code/significant, copyrightable content in public header files (i.e. significant content that’s not straight interface definitions)

Q: Why is fts.h not included?

It’s impossible to match the glibc ABI for fts because the glibc ABI is [unusably broken]. This also means that no working software can be built using the built-in fts from glibc; anything using fts is either already including its own copy (there is a canonical BSD version and gnulib has it too), or is hopelessly broken on glibc and the maintainers are just unaware of that fact. So including it in musl would not help anything at this time. If glibc bug 15838 is fixed by adding an fts64 interface in glibc, we could consider supporting it with a matching ABI in musl, but it seems more likely that glibc will just deprecate this interface.

Q: Do I need to define _LARGEFILE64_SOURCE to get 64bit off_t?

note that if you’re building a whole system with musl you never need any of them. you don’t need them for building musl, and you don’t need them for building apps against musl (but they won’t hurt, generally, either).

Q: Why am I getting “error: redefinition of struct ethhdr/tcphdr/etc”?

The application you’re trying to compile mixes userspace and kernel headers (/include/linux). The kernel headers are notoriously broken for userspace and clash with the definitions provided by musl. It only works (in certain cases) with GLIBC because…

the issue can be fixed in different ways:

Q: Why is the utmp/wtmp functionality only implemented as stubs?

Q: My dynamically linked program crashes on PowerPC!

Make sure you pass -Wl,--secure-plt when you use dynamic linking. Musl only supports the secure plt. To check if your binary is correct, use readelf -a a.out | grep PPC_GOT. It should list at least one line. There’s also a known bug in binutils 2.22: http://sourceware.org/bugzilla/show_bug.cgi?id=13470 Be sure to use the patches attached there. in order to test for this issue, create a small test program that uses environ:

#include <stdio.h>
extern char** environ; int main() {dprintf(2, "%p\n", environ);}

If that crashes, despite having PPC_GOT entries, you are affected. Further, you should build gcc with the option --with-long-double-64 --enable-secureplt. Additionally use this patch.

Q: Busybox linked against musl segfaults on ARM!

The bug is probably --sort-section renders busybox unusable on ARM.

Use this fix: sed -i 's,SORT_SECTION=,SORT_SECTION= #,' scripts/trylink

Q: When compiling something against musl, I get error messages about sys/cdefs.h

Congratulations, you have found a bug! The bug is in the application that uses this internal glibc header. This header is not intended to be used by any program. File a bug report. Until it gets fixed, patch the program to remove the include line and replace all occurrences of:

__BEGIN_DECLS

with

#ifdef __cplusplus
extern "C" {
#endif

and all occurrences of

__END_DECLS

with

#ifdef __cplusplus
}
#endif

Q: I’m trying to compile something against musl and I get lots of error messages!

musl is strict about namespaces. As a quick fix, add to your CFLAGS -D_GNU_SOURCE for GNU- and Linux-specific functions like strndup, and add -D_BSD_SOURCE for BSD-specific functions like strlcpy. If you are the maintainer of the package, consider determining the correct namespace and adding it to the relevant .c files. Article about feature test macros on lwn.net.

Q: Building musl fails with internal compiler error in src/complex/__cexp.c

Some versions of gcc fail to compile the cpack compound literal used in the complex code, the quick fix is to remove src/complex (it will remove complex math support).

Q: Application XY misbehaves or crashes at runtime when linked against musl

Usually this is because the app has hardcoded glibc-specific assumptions or wrong #ifdefs. See Functional differences from glibc. The most common causes are expectations of gnu getopt behaviour, iconv usage on UCS2 with assumptions that BOM is processed and the byte order detected, assuming that off_t is 32 bit, and assumptions that pthread_create will create sufficiently large stacks by default (crash situation). A good approach to solving the issue is to watch out for #if and #ifdefs in the code and placing some debug #warning there to see which code paths are enabled by the preprocessor. Often the logic taken by #ifdef’s is to check a blacklist of preprocessor defines #if __sun__ || __haiku__ || __irix__ || __qnx__ portable_code(); #else glibc_code() #endif. The logic should be the other way round: #ifndef __GLIBC__ portable_code() #else glibc_code(). There’s also no point in checking __GLIBC__ version numbers without first making sure that __GLIBC__ is defined at all.

Q: I’m getting a gnulib error

freadahead.c:87:3: error: #error "Please port gnulib freadahead.c to your platform!
Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib."

Congratulations, you have just encountered gnulib, the GNU “portability” library! The special “appeal of this "portability” library is that it has been copied into the source tree of many programs (especially GNU ones). Thus you can’t fix it once and be done, you have to fix it in every single program that uses it. The authors of this library think it is a good idea to let you run into a compilation error instead of offering a portable fallback version of their code, so they can show you their muscles when you come to ask for help as the error message suggests to do. See http://www.mail-archive.com/bug-gnulib@gnu.org/msg27386.html and http://www.mail-archive.com/search?q=musl&l=bug-gnulib%40gnu.org.

To fix it, either update the in-tree gnulib (no idea how to do that), or use a hack: each one of the gnulib function is triggered by a configure test, the condition being either “libc doesnt have this function” or “this libc function doesnt behave like GNUlib dictators want it to be”. All of those configure checks use a cache variable like “gl_cv_func_isnanl_works=yesbigger list.

So, you can prevent their code getting compiled in when you start configure with ./configure gl_cv_func_isnanl_works=yes. Alternatively, you can put all of these symbols into a file called config.cache and run ./configure -C (the -C makes configure pick up the cache), so all these checks will be skipped.

To prevent additional breakage, overwrite all .c files in the gnulib folder that try to replace libc functionality with an empty file. If that’s still not enough to make gnulib happy, you may have to do additional preprocessor hacks so their “rpl_” functions get again mapped to the real libc thing.

For example: CFLAGS="-Dgnu_fnmatch=fnmatch -Drpl_getgroups=getgroups -Drpl_nanosleep=nanosleep -Drpl_futimens=futimens" ./configure1.

Q: None of these are questions!

Why would the Frequently Aired Quandaries page have questions?