Cross-compiling libX11 with musl

Development
1

I’m trying to build libX11 with musl using nix-build -A pkgsCross.musl64.xorg.libX11, however it fails with:

[...]
/nix/store/[...]-binutils-2.31.1/bin/ld: cannot find -lc

Full log here.

I know this error can usually be fixed by adding glibc.static to buildInputs; but when building with musl instead of glibc that doesn’t make sense.
Alpine doesn’t use any special options to build it with musl.

Does anybody have experience with -lc and musl? Should I just patch away all usages of -lc?

1 Like
2

@matthewbauer @nh2 @dtzWill maybe?

3

If I understand correctly, pkgs.pkgsCross.musl64 is technically a cross compilation toolchain, which uses a compiler that is itself linked against glibc, uses a bunch of platform triples everywhere, and outputs binaries that are linked against musl. This is surely still some kind of bug in one of many possible components, but likely caused by cross compiling being weird.

$ ldd $(nix-build --no-out-link "<nixpkgs>" -A pkgsCross.musl64.stdenv.cc.cc)/bin/x86_64-unknown-linux-musl-gcc
	linux-vdso.so.1 (0x00007fff583e8000)
	libm.so.6 => /nix/store/pnd2kl27sag76h23wa5kl95a76n3k9i3-glibc-2.27/lib/libm.so.6 (0x00007fb7db9f6000)
	libc.so.6 => /nix/store/pnd2kl27sag76h23wa5kl95a76n3k9i3-glibc-2.27/lib/libc.so.6 (0x00007fb7db840000)
	/nix/store/pnd2kl27sag76h23wa5kl95a76n3k9i3-glibc-2.27/lib/ld-linux-x86-64.so.2 => /nix/store/pnd2kl27sag76h23wa5kl95a76n3k9i3-glibc-2.27/lib64/ld-linux-x86-64.so.2 (0x00007fb7dbb8e000)

Notice the triple in the compiler binary name, and that it’s linked against glibc, even though the stdenv will produce packages linked against musl.

pkgs.pkgsMusl, on the other hand, is just a normal package set that just bootstraps a compiler the normal way, but replaces glibc with musl everywhere. pkgs.pkgsMusl.xorg.X11 built just fine for me, and got a lot more from the binary cache than pkgsCross.musl64 did.

$ ldd $(nix-build --no-out-link "<nixpkgs>" -A pkgsMusl.stdenv.cc.cc)/bin/gcc
	linux-vdso.so.1 (0x00007ffda62fe000)
	libc.so => /nix/store/javypr9lls4hm88znp4mcyp78qphgpzx-musl-1.1.22/lib/libc.so (0x00007fd352751000

Notice that the gcc binary in use is itself linked against a libc.so from musl.

4

ElvishJerricco’s reply makes sense to me.

In situations like this I would usually add -v flags (or V=1 or VERBOSE=1 to Makefiles) to trace down which compiler is invoked, which linker it invokes, and with what flags.

5

I think this is upstream issue !100 which was fixed by !22 and included in version 1.6.9. As of writing nixpkgs is on version 1.6.8.