musl-libc | Musl-libc copy git

After a lot of hit and trials, I was able to successfully build the toolchain.

The musl-libc is smart, it defines those types itself. So the rpc headers https://code.woboq.org/userspace/glibc/sunrpc/rpc/types.h.html#77 here were conflicting with the types __u_char that GNU defines but does not define u_char and more.

We can solve this by passing -D__daddr_t_defined -D__u_char_defined macros to the c flags on build.

All the wrapper does is remove the default library and include paths and add replacement ones. Otherwise, it relies on the compiler's view of the ABI being sufficiently matched that a GCC that thinks it's targeting glibc (*-linux-gnu) works with a musl (*-linux-musl) target.

A full GCC toolchain has a number of "target libraries" - libraries that are linked into the output program to provide some functionality the compiler offers. This includes libgcc (software multiply or divide, software floating point, etc. according to whether the target arch needs these things, and unwinding support for exception handling), libstd++ (the C++ standard library), and a number of other things like libgomp (GNU OpenMP runtime implementation for use with #pragma OMP ...). In theory all of these possibly depend on the specific target ABI, including the libc, and potentially link to symbols from libc. In practice, for the most part libgcc doesn't, and is "safely" reusable with a different libc as long as the basic type definitions and a few other ABI things match.

For the other libraries with more complex dependencies on libc, it's generally not expected that a build against one libc would work with a different one. musl libc provides some degree of ABI-compat for using glibc-linked libraries, so there's some hope that they'd work anyway, but you'd need to copy them to the new library path. However, GCC's C++ standard library headers also seem to have some heavy dependency on the (libc) system headers for the target, and when setup for glibc do not seem to work with musl. There is probably some way to make this work (i.e. to add C++ support to the wrapper), but it's an open problem exactly how to do it.

Even if this could be made to work, though, the deeper you go, the more reasons you're likely to find that you'd rather just have a proper cross-compiler toolchain that knows it's targeting musl. And nowadays these are easy enough to build. But if you find you're needing additonal third party libraries too, and don't want to build them yourself, it probably makes more sense to just use a Docker image (or other container) with a distro that provides library binaries for you.

The code in lines 7 - 14 loads the parameters to the syscall in parameter order. Since RDI is loaded at line 8, its value is saved in R11 so that it can be written to parameter 8 (on the stack) at line 14.

In hand-written assembly code, it can be easier to understand and maintain by keeping things organized like this, which outweighs the cost of an extra move instruction.

To detect the libc name and version at compile time, you can check for preprocessor macros. The following script is just a proof of concept:

That's not generic SHA-256 message digest algorithm but a specific algorithm used by the crypt(3) password hashing function. See the documentation for that function on how it is used.

The whole point of the musl-gcc wrapper script is to invoke gcc with the include and library paths adjusted to isolate it from the host include and library ecosystem (which are assumed to be glibc-based). That includes the kernel headers for your host system. If you want to use any libraries (including "header-only libraries" like the kernel headers) with musl-gcc, you need to build a version against musl instead of glibc and install it in the musl include/library path.

For kernel headers, they don't actually depend on the libc or have any library files; it's just the headers. So you can probably get by with copying (or symlinking) the linux, asm, and asm-generic directories from /usr/include to the musl include dir. Alternatively you can install them from kernel sources.

If you find you need any significant amount of third-party library stuff, though, it makes more sense to just drop musl-gcc and use a real cross-compiler. You can get prebuilt binary ones if you're willing to trust them from musl.cc, or build your own (takes about 15 minutes on a typical system nowadays) with musl-cross-make. This will give you kernel headers automatically, as well as a full set of GCC target libraries that let you build C++ software, OpenMP-using software, etc.

The include paths in your question are all glibc files, so it looks like the library you're trying to link to was built with glibc. This can sometimes be made to work, but there are limitations. In your case, it was built with the glibc version of _FORTIFY_SOURCE, which uses symbols from glibc that are not presently available in musl (the _FORTIFY_SOURCE implementation typically used on musl works differently). Making this work has been on the long-term agenda for a long time, but not a priority; if you can, it's much better to rebuild the library against musl.

In your BSP layer you'll find the following parameter:

Just in (May/19) - openjdk9 (experimental) for AArch64 is now available from Alpine repositories!

Package details: https://pkgs.alpinelinux.org/package/edge/testing/aarch64/openjdk9

Grab it using: