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]
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
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.
There isn't one. You can specify the library search path by creating or editing
the file /etc/ld-musl-$ARCH.path, where $ARCH is the string identifying your
architecture (look at what /lib/ld-musl-*.so.1 uses if uncertain). Paths can
be separated by newlines or colons. The environment variables LD_PRELOAD and
LD_LIBRARY_PATH are also supported for one-off cases.
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)
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.
- Those options are for building apps, not building libc.
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCEhave nothing to do with supporting large files properly but with exposing the idiotic legacy interfaces with 64 on the end of their names (like open64, lseek64, etc.). only-D_FILE_OFFSET_BITS=64should ever be used, anywhere, even on glibc.- under musl,
off_tis always 64-bit. the-D_LARGEFILE64_SOURCEoption is however honored to support compiling applications using the legacy open64, etc. nonsense, but it just #defines them away to the version without 64 on the end.
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).
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 userspace headers just include the kernel headers, and
- because the kernel headers have a hardcoded compatibility fix for GLIBC to
prevent exactly this issue (
linux/libc-compat.h)
the issue can be fixed in different ways:
- remove the linux/ include directives
- use the patched kernel-headers package from sabotage linux
- factor out the code needing the kernel headers into a separate compilation unit which doesn't use any userspace headers
- copy the required struct definitions into an internal header and rename them.
- if the feature is implemented, you need to take additional measures to protect your user's privacy
- in order to use the utmp/wtmp feature, you need a suid/sgid binary to modify the database, which opens the door for security issues:
- if you compromise those binaries, you can inject arbitrary data into the db, that other programs might interpret in exploitable ways
- that's a HUGE risk to pay for the sake of a basically-useless and possibly-harmful "feature"
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.
The bug is probably --sort-section renders busybox unusable on ARM.
Use this fix: sed -i 's,SORT_SECTION=,SORT_SECTION= #,' scripts/trylink
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_DECLSwith
#ifdef __cplusplus
extern "C" {
#endifand all occurrences of
__END_DECLSwith
#ifdef __cplusplus
}
#endifmusl 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.
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).
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.
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/[email protected]/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 doesn't have this function" or "this libc function
doesn't behave like GNUlib dictators want it to be". All of those configure
checks use a cache variable like "gl_cv_func_isnanl_works=yes" bigger 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" ./configure ... 1.
Why would the Frequently Aired Quandaries page have questions?