musl-cross, native-musl, cross fixes, oh my! #34645

dtzWill · Feb 6, 2018

Motivation for this change

Support cross-compiling for musl, support musl-native, generalize a bit beyond glibc, many cross fixes.

A few fixes are "borrowed" from @bgamari's big PR (#30882).

PR History

To help folks track changes made across updates to this PR, I'm tagging each revision to help diff and whatnot:

v1 - 2018-02-05
- Initial submission.
v2 - 2018-02-06
- Drop musl.nix, musl-cross.nix (commits introducting and modifying)
- Drop 305a63407ed352bda7b13f432be2c79df2bde4be (gcc6 yesFuncs/noFuncs):
  - doesn't seem needed, and as a bonus wasn't used for stdenv.cc anyway so no mass rebuild
- busybox: don't force gcc
- libcap: don't force gcc, also cleanup to use depsBuildBuild and existing env vars
- musl: don't redundantly add cross prefix
- Drop stdenv.is{Glibc,Musl}, grab from hostPlatform
- Drop openjdk commit/revert, will revisit later
- pam: depsBuildBuild
v3 - 2018-02-08
- rebase onto latest master
- resolve squid4 conflict by dropping commit: fix no longer needed, can enable parallel building in separate PR
- re-enable LLVM manpage building on musl, only disable on cross (for now).
v4 - 2018-02-08
- drop 'libc = "glibc"' from system examples
- rebase onto staging, since that's what we're targeting. Whoops.
v5 - 2018-02-09
- specify commit hash in gcc5 musl patch URL
- resolve conflict with nixUnstable, rebase onto latest staging
- fix typo in "examples" for aarch64-musl introduced in v4
- tweak llvm-{4,5} use of python to (hopefully) fix darwin eval, allow either python2 or python3
- fix go eval problems by replacing attempts to use stdenv.glibc
v6 - 2018-02-11
- resolve conflicts, rebase onto latest staging
- groundwork for musl32, although no bootstrap here and cross doesn't work yet
- restore "stdenv.glibc", too messy to remove as part of this and can be done later.
v7 - 2018-02-11
- refactor lib changes into #34861, rebase onto that and latest staging
- drop nearly all LLVM/clang fixes from this, will tackle in follow-up
- lots of cleanup, esp. re:isGlibc/isMusl and breaking apart / merging commits (~50 fewer commits!)
v8 - 2018-02-11
- fetch patches instead of local copies: net-snmp, apparmor, audit
- don't use IFD for systemd patch list and instead generate postPatch command
v9 - 2018-02-12
- drop unused python patch
- support musl-native bootstrapping on aarch64, armv6l (in addition to x86_64). Not tested yet 😇.
v10 - 2018-02-13
- rebase onto latest staging, resolve systemd 237 conflicts by dropping patches used to get it building. Will revisit later due to effort involved and amount of patches required.
- use 64bit busybox for bootstrap on x86_64 to avoid problems like those reported in WSL.
- actually restore "stdenv.glibc" (for now), previous commit did not do this for final stdenv
- tested bootstrap on aarch64 (hooray and thank you @grahamc and https://github.com/nix-community/aarch64-build-box), it's at least not completely broken.
- includes XZ fix (#34916) since without it stdenv contains invalid referencces

TODO

use fetchpatch instead of introducing local files, make a pass checking for this

Minor / Misc / Maybe

cc-wrapper: When building gcc6 (wrapped) in cross stdenv, somehow binutils from host get onto PATH (?) causing the wrong mkdir to be used. This doesn't occur when building the cross stdenv.cc, FWIW. Example error:

/nix/store/k1r93q2cq3r7x8kx663w8lf0qaid7iiv-stdenv/setup: line 1224: /nix/store/ldsqyff47p1v0yqjp4a3kzxcqvv5fmwr-coreutils-8.29-armv6l-unknown-linux-musleabihf/bin/mkdir: cannot execute binary file: Exec format error

refactor duplicated code compute path to getent utility

Quickstart with Binary Cache

To enjoy musl goodness right away, consider taking advantage of the ALLVM project's binary cache!

To do so, add the following to your configuration.nix:

{
    nix.binaryCaches = [
      "https://cache.nixos.org/"
      "https://cache.allvm.org/"
    ];

    nix.binaryCachePublicKeys = [
      "gravity.cs.illinois.edu-1:yymmNS/WMf0iTj2NnD0nrVV8cBOXM9ivAkEdO1Lro3U="
    ];
}

(Please add it after the nixos one O:))

Equivalent of "small" jobset is evaluated and cached for a few build configurations,
but certainly not everything works yet. This is just a (hopefully solid) start!

Credits and Teasers: ALLVM

This PR (and many of the related fixes submitted recently) are based on work done as part of the ALLVM project, many thanks to our funding 👍.

We look forward to sharing more with everyone soon! Stay tuned :).

Ericson2314 · Feb 6, 2018

Ericson2314 reviewed Feb 6, 2018

View changes

Yayaayyyayayayayyayayayayyayayaayayayy!

Here's a few comments from a quick (relative to the size of this at least!) first pass. Very excited to merge this!

Ericson2314 · Feb 6, 2018

pkgs/stdenv/linux/default.nix

-  }.${localSystem.system}
-    or (abort "unsupported platform for the pure Linux stdenv")
+, bootstrapFiles ?
+  let table = {


Maybe we should just use config?

I don't think "config" is canonical for a a given system/libc pair. I'm not sure how important that is, but that's why I did things this way.

Yeah makes sense.

Ericson2314 · Feb 6, 2018

lib/systems/default.nix

@@ -26,7 +26,9 @@ rec {
      libc =
        /**/ if final.isDarwin then "libSystem"
        else if final.isMinGW  then "msvcrt"
-        else if final.isLinux  then "glibc"
+        else if final.isLinux && final.isGlibc then "glibc"


I'm not wild about how libc and the new is* predicates are somewhat disconnected. But I see its the best choice given how things are today. Maybe the solution is to move libc into parsed?

I'm not sure. Related: It seems "abi" dictates the libc to be used, at least if it's not "unknown"...

Hmm, I trust you on this but happy to give feedback on your thoughts.

Ericson2314 · Feb 6, 2018

lib/systems/examples.nix

@@ -63,6 +63,20 @@ rec {
    platform = platforms.fuloong2f_n32;
  };

+  muslpi = raspberryPi // {
+    config = "armv6l-unknown-linux-musleabihf";
+    libc = "musl";


Are the libc = ...s needed? I'd love to remove them everywhere and have inference take care of it; the more minimal these attribute sets are the better!

I don't think so! This one is "needed" only because I base it off of "raspberryPi" which explicitly sets libc to glibc; if it didn't I wouldn't need to override it.

AFAIK they're inferred properly by default in all examples in this file.

Which, by the way, is magical :D.

Ericson2314 · Feb 6, 2018

musl-cross.nix

@@ -0,0 +1,5 @@
+{ src ? ./default.nix }:


Errr should we have new top level files? I do want an easier way to get people going, but not sure what should be it.

Oh no! This was just for my testing--especially early on before recent improvements -- to avoid error-prone and/or long nix incantations. This should 0% be merged anywhere, I'll drop it sorry.

Ericson2314 · Feb 6, 2018

pkgs/development/compilers/gcc/6/default.nix

@@ -314,7 +324,44 @@ stdenv.mkDerivation ({
  + stdenv.lib.optionalString (langJava || langGo) ''
    export lib=$out;
  ''
-  ;
+  + stdenv.lib.optionalString (buildPlatform != hostPlatform)


Do we need these? I haven't needed them so far.

I'll check, the commits re:gcc6 (and in a few other places in this PR) are still a bit "exploratory" and showing something that works vs "ready to merge" and clean-- and likely are not minimal.

Not at all being defensive :) just FYI, and good question I'll check. I hope you're right!

Ericson2314 · Feb 6, 2018

pkgs/os-specific/linux/musl/default.nix


+  cross = if buildPlatform != hostPlatform then hostPlatform else null;


Not a fan of these sorts of cross args. glibc is a bad derivation style!

xD. Turns out it's only needed for adding the cross suffix... O:).

Ericson2314 · Feb 6, 2018

pkgs/os-specific/linux/musl/default.nix

 stdenv.mkDerivation rec {
-  name    = "musl-${version}";
+  name    = "musl-${version}" +
+    lib.optionalString (cross != null) "-${cross.config}";


Adapter should already do this, right? (I recently removed redundency from glibc.)

Oh! Yes adapter of course does do this, I assumed/guessed this was for libcCross which is a bit "special".

That said, it does result in a lot of redundancy as-is because "build != host" is not how you check "am I being built as libcCross"! Also it might not be needed even then...yep it sure doesn't appear to be needed then either.

Ah yes, I probably was following along glibc, from before that change.

I'll remove this, although immediately reverting it to avoid mass-rebuild while working on other issues.

Ericson2314 · Feb 6, 2018

pkgs/servers/monitoring/net-snmp/CVE-2015-5621.patch

@@ -0,0 +1,132 @@
+From 3714c5be3212d2af61545439eeb432e5d84a8d39 Mon Sep 17 00:00:00 2001


Can we not fetchPatch this?

I'll check. In general I preferred, mostly for convenience, to make local copies of patches.

This isn't the "Nixpkgs Way", I'll see what can be fetchpatch'd here and elsewhere.

Ericson2314 · Feb 6, 2018

pkgs/stdenv/linux/default.nix

@@ -95,7 +107,7 @@ let

          # stdenv.glibc is used by GCC build to figure out the system-level
          # /usr/include directory.
-          inherit (prevStage) glibc;
+          # inherit (prevStage) glibc;


Yay! stdenv.glibc is an awful attribute.

Yes! Very glad you agree. So far doesn't seem to be used for anything worthwhile.

Ericson2314 · Feb 6, 2018

pkgs/stdenv/generic/default.nix

@@ -117,7 +117,8 @@ let
      # Utility flags to test the type of platform.
      inherit (hostPlatform)
        isDarwin isLinux isSunOS isHurd isCygwin isFreeBSD isOpenBSD
-        isi686 isx86_64 is64bit isArm isAarch64 isMips isBigEndian;
+        isi686 isx86_64 is64bit isArm isAarch64 isMips isBigEndian
+        isMusl isGlibc;


I want to deprecate these in 18.03 to force people to think about cross. What do you think? If so, maybe we shouldn't add anymore here.

Works for me! I'll make a pass removing these. I do like having "isMusl" and "isGlibc"-- they're less error-prone than libc == "stringvalue". But accessing them from the appropriate platform (hostPlatform) sounds good to me.

Ericson2314 · Feb 8, 2018

Ericson2314 reviewed Feb 8, 2018

View changes

Ericson2314 · Feb 8, 2018

lib/systems/examples.nix

@@ -63,6 +63,18 @@ rec {
    platform = platforms.fuloong2f_n32;
  };

+  muslpi = (removeAttrs raspberryPi [ "libc" ]) // {


Err I meant literally remove libc from raspberryPi above. It should be inferred just fine!

Haha, sure thing. I agree that's nicer/cleaner, I just already feel I touch "unrelated" things in this PR and leaving existing examples as-is seemed easiest way to make it easy for reviewers to see I don't break them :).

Anyway, removed!

Whoops rebasing onto master while targetting staging was a dumb idea. Will fix shortly.

dtzWill · Feb 8, 2018

Whoops rebasing onto master while targetting staging was a dumb idea. Will fix shortly.

Mic92 · Feb 9, 2018

Mic92 reviewed Feb 9, 2018

View changes

Mic92 · Feb 9, 2018

pkgs/development/compilers/gcc/5/default.nix

-      ++ optional stdenv.cc.isClang ./libcxx38-and-above.patch;
+      ++ optional stdenv.cc.isClang ./libcxx38-and-above.patch
+      ++ optional stdenv.hostPlatform.isMusl (fetchpatch {
+        url = "https://raw.githubusercontent.com/richfelker/musl-cross-make/master/patches/gcc-5.3.0/0001-musl.diff";


Better to use a commit hash here, just to be sure.

Good catch, agreed. Done!

danbst · Feb 12, 2018

danbst reviewed Feb 12, 2018

View changes

danbst · Feb 12, 2018

pkgs/development/interpreters/python/cpython/2.7/default.nix

+    ] ++ [
+
+      # Don't use pass host PYTHONPATH to build python
+      #./cross-compile.patch


probably remove the patch then?

Good catch, thanks! Done!

systemd update changed expression significantly, will resolve soon
am seeing stdenv retaining references it shouldn't, investigating now/first

EEP more investigation required but it appears "xz" currently contains reference to bootstrap tools on master (for glibc), at least when built with Nix 2.0 (although not sure if it's limited to that)!

Will create issue for this...

dtzWill · Feb 13, 2018

systemd update changed expression significantly, will resolve soon
am seeing stdenv retaining references it shouldn't, investigating now/first

EEP more investigation required but it appears "xz" currently contains reference to bootstrap tools on master (for glibc), at least when built with Nix 2.0 (although not sure if it's limited to that)!

Will create issue for this...

Systemd 237 w/musl: WIP, may fix in followup instead

Bah systemd 237 is a pain, currently sorting what to do about its new use of glibc-only FTW_ACTIONRETVAL (and FTW_STOP): systemd/systemd@ed457f1#diff-3560f8a726af91387da20cfc878fea11 . We'll see...

Another gem, this time locally declaring functions specific to glibc internal implementation (not even exported by glbc's headers, not safe to rely on even with glibc):
systemd/systemd@5c30a6d#diff-4455c5d492b8b6c422f8c86c2929f861R942 . Maybe we can just call pthread_atfork on musl ?

Looks like might need to punt on systemd for this PR and revisit later :(.

dtzWill · Feb 13, 2018

Systemd 237 w/musl: WIP, may fix in followup instead

Bah systemd 237 is a pain, currently sorting what to do about its new use of glibc-only FTW_ACTIONRETVAL (and FTW_STOP): systemd/systemd@ed457f1#diff-3560f8a726af91387da20cfc878fea11 . We'll see...

Another gem, this time locally declaring functions specific to glibc internal implementation (not even exported by glbc's headers, not safe to rely on even with glibc):
systemd/systemd@5c30a6d#diff-4455c5d492b8b6c422f8c86c2929f861R942 . Maybe we can just call pthread_atfork on musl ?

Looks like might need to punt on systemd for this PR and revisit later :(.

@dtzWill I am pretty sure systemd was never compatible with musl libc.

Mic92 · Feb 13, 2018

@dtzWill I am pretty sure systemd was never compatible with musl libc.

Ericson2314 · Feb 13, 2018

Ericson2314 reviewed Feb 13, 2018

View changes

Ericson2314 · Feb 13, 2018

pkgs/development/libraries/libbfd/default.nix

    cd bfd
  '';

  nativeBuildInputs = [ autoreconfHook264 bison ];
  buildInputs = [ libiberty zlib ];

-  configurePlatforms = [ "build" "host" ];


Err its still good to have these in all cases, I think. I'd do that for all autoconf-based packages if I could easily tell them apart.

Oh? Hmm sorry. I thought configurePlatforms was .. .oh, it's not set on cross is it? Okay I'll restore this.

It gets set to that on cross, but I rather have it always set that way, for packages that support it. See the mkDerivation definition for this.

Ericson2314 · Feb 13, 2018

pkgs/development/libraries/libbfd/default.nix

  ];

  # We just want to build libbfd
-  postPatch = ''
+  postAutoreconf = ''


I'm not sure about this either? We are only building in the bfd subdirectory, so shouldn't need to autoreconf the outer stuff. I also don't think the hook is recursive and will properly descend either.

Hmm I'll look into this. FWIW the update hook is recursive: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/update-autotools-gnu-config-scripts.sh .

And unpacking binutils it appears config.guess and config.sub are at the top-level, not in the bfd directory, which is why it's important for the update to happen at the top-level.

(FWIW the problem this fixes is configure complaining it doesn't recognize the platform)

I think what we'd ideally do is this:

update hook runs at top-level, first

autoreconf happens, in bfd directory

It appears the hooks are both added to preConfigurePhases, with the update happening after autoreconf which is unfortunate. Lemme see..

dezgeg · Feb 13, 2018

I think you could instead move the cd bfd so that it happens after updateAutotoolsGnuConfigScriptsPhase.

Also, does this package really need autoreconfHook264 nowadays instead of a recent version? Maybe that's enough to fix it.

Yes re:needing that specific autotools-- it complains loudly if anything other than that exact version is used :(.

Not sure there's a good way to do what you said, if you have something that works let me know!

Meh.

I guess we could make all autoconf versions copy the recent version of config.sub and config.guess from gnu-config instead of the version that they vendor in?

Can you try if staging...dezgeg:upgrade-autoconf111-config-scripts works?

FYI, I just noticed that some of the new musl stuff won't build with gcc-7, e.g. https://hydra.nixos.org/build/69495411

vcunat · Feb 18, 2018

FYI, I just noticed that some of the new musl stuff won't build with gcc-7, e.g. https://hydra.nixos.org/build/69495411

Can you try if staging...dezgeg:upgrade-autoconf111-config-scripts works?

This doesn't fix the issue for me, does it for you? This is what I get:

@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
unpacking source archive /nix/store/qhhhmq6aj185lfs2x3sas708h23g5pml-binutils-2.28.1.tar.bz2
source root is binutils-2.28.1
setting SOURCE_DATE_EPOCH to timestamp 1500992977 of file binutils-2.28.1/md5.sum
@nix { "action": "setPhase", "phase": "patchPhase" }
patching sources
applying patch /nix/store/q9pypsrw5slh7m607scrbx7y6bbn01bl-new-dtags.patch
patching file ld/ldmain.c
Hunk #1 succeeded at 280 with fuzz 1 (offset -16 lines).
applying patch /nix/store/wy1lrg34fw2f1msbiws3b60n8wmg8rvn-dtneeded.patch
patching file ld/ldmain.c
Hunk #1 succeeded at 310 with fuzz 1 (offset 12 lines).
applying patch /nix/store/sqbhaaayam0xw3a3164ks1vvbrdhl9vq-deterministic.patch
patching file ld/ldlang.c
Hunk #1 succeeded at 3199 with fuzz 1 (offset 104 lines).
applying patch /nix/store/warg8i0kjfr2hkc3lz3kwfgj9q8hvny3-pt-pax-flags.patch
patching file bfd/elf-bfd.h
Hunk #1 succeeded at 1785 with fuzz 2 (offset 519 lines).
patching file bfd/elf.c
Hunk #1 succeeded at 1546 (offset 461 lines).
Hunk #2 succeeded at 3010 (offset 663 lines).
Hunk #3 succeeded at 4301 (offset 971 lines).
Hunk #4 succeeded at 4967 with fuzz 2 (offset 1013 lines).
Hunk #5 succeeded at 6488 (offset 1336 lines).
Hunk #6 succeeded at 6498 with fuzz 2 (offset 1336 lines).
patching file bfd/elflink.c
Hunk #1 succeeded at 5919 with fuzz 1 (offset 155 lines).
Hunk #2 succeeded at 5958 (offset 155 lines).
patching file binutils/readelf.c
Hunk #1 succeeded at 3779 (offset 1486 lines).
patching file include/bfdlink.h
Hunk #1 succeeded at 379 with fuzz 2 (offset 66 lines).
patching file include/elf/common.h
Hunk #1 succeeded at 465 (offset 42 lines).
Hunk #2 succeeded at 476 (offset 42 lines).
patching file ld/emultempl/elf32.em
Hunk #1 succeeded at 2565 with fuzz 1 (offset 426 lines).
patching file ld/ldgram.y
Hunk #1 succeeded at 1244 (offset 171 lines).
patching file ld/lexsup.c
Hunk #1 succeeded at 1819 (offset 26 lines).
applying patch /nix/store/jxhica5y04jd182c2b3xzap31ixxplw2-no-plugins.patch
patching file bfd/plugin.c
Hunk #1 succeeded at 334 (offset 1 line).
Hunk #2 succeeded at 366 (offset 1 line).
applying patch /nix/store/wilglaz00r3zpqy6j5awrzia446lzmk9-disambiguate-arm-targets.patch
patching file bfd/elf32-arm.c
applying patch /nix/store/pa83jbilxjpv5d4f62l3as4wg2fri7r7-always-search-rpath.patch
patching file ld/genscripts.sh
applying patch /nix/store/wlh3fqr3k9wrymvg83y3xi3dvqkwmca1-build-components-separately.patch
patching file bfd/configure.ac
patching file opcodes/Makefile.am
patching file opcodes/configure.ac
applying patch /nix/store/s3z9xjfl3ppms5m33j0pyrq07280l93c-bfd-1-disable-subdir-doc.patch
patching file bfd/Makefile.am
patching file bfd/Makefile.in
Hunk #1 succeeded at 371 (offset 32 lines).
@nix { "action": "setPhase", "phase": "autoreconfPhase" }
autoreconfPhase
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I . -I .. -I ../config
main::scan_file() called too early to check prototype at /nix/store/2zniw2qmqxzy5kjwxs5z79qyn3jkp3sv-automake-1.11.6/bin/.aclocal-wrapped line 644.
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '..'.
libtoolize: copying file '../ltmain.sh'
libtoolize: putting macros in '.'.
libtoolize: copying file './libtool.m4'
libtoolize: copying file './ltoptions.m4'
libtoolize: copying file './ltsugar.m4'
libtoolize: copying file './ltversion.m4'
libtoolize: copying file './lt~obsolete.m4'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
main::scan_file() called too early to check prototype at /nix/store/2zniw2qmqxzy5kjwxs5z79qyn3jkp3sv-automake-1.11.6/bin/.aclocal-wrapped line 644.
autoreconf: running: /nix/store/3hb5j83il656vpf9rzf014n0fln4f703-autoconf-2.64/bin/autoconf --force
autoreconf: running: /nix/store/3hb5j83il656vpf9rzf014n0fln4f703-autoconf-2.64/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /nix/store/2zniw2qmqxzy5kjwxs5z79qyn3jkp3sv-automake-1.11.6/bin/automake line 4159.
configure.ac:28: installing `../missing'
Makefile.am: installing `../depcomp'
autoreconf: Leaving directory `.'
@nix { "action": "setPhase", "phase": "configurePhase" }
configuring
configure flags: --disable-static --disable-dependency-tracking --prefix=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1 --bindir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/bin --sbindir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/sbin --includedir=/nix/store/48w6c91d47fhhpjp3s9165pxhiqlh0kk-libbfd-2.28.1-dev/include --oldincludedir=/nix/store/48w6c91d47fhhpjp3s9165pxhiqlh0kk-libbfd-2.28.1-dev/include --mandir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/share/man --infodir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/share/info --docdir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/share/doc/libbfd --libdir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/lib --libexecdir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/libexec --localedir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/share/locale --enable-targets=all --enable-64-bit-bfd --enable-install-libbfd --enable-shared --with-system-zlib --build=x86_64-unknown-linux-musl --host=x86_64-unknown-linux-musl
checking build system type... Invalid configuration `x86_64-unknown-linux-musl': machine `x86_64-unknown-linux' not recognized
configure: error: /nix/store/qlyk4p97g9lc6dxwjkqb0ilbi0dm8lqv-bash-4.4-p12/bin/bash ./../config.sub x86_64-unknown-linux-musl failed

dtzWill · Feb 19, 2018

Can you try if staging...dezgeg:upgrade-autoconf111-config-scripts works?

This doesn't fix the issue for me, does it for you? This is what I get:

@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
unpacking source archive /nix/store/qhhhmq6aj185lfs2x3sas708h23g5pml-binutils-2.28.1.tar.bz2
source root is binutils-2.28.1
setting SOURCE_DATE_EPOCH to timestamp 1500992977 of file binutils-2.28.1/md5.sum
@nix { "action": "setPhase", "phase": "patchPhase" }
patching sources
applying patch /nix/store/q9pypsrw5slh7m607scrbx7y6bbn01bl-new-dtags.patch
patching file ld/ldmain.c
Hunk #1 succeeded at 280 with fuzz 1 (offset -16 lines).
applying patch /nix/store/wy1lrg34fw2f1msbiws3b60n8wmg8rvn-dtneeded.patch
patching file ld/ldmain.c
Hunk #1 succeeded at 310 with fuzz 1 (offset 12 lines).
applying patch /nix/store/sqbhaaayam0xw3a3164ks1vvbrdhl9vq-deterministic.patch
patching file ld/ldlang.c
Hunk #1 succeeded at 3199 with fuzz 1 (offset 104 lines).
applying patch /nix/store/warg8i0kjfr2hkc3lz3kwfgj9q8hvny3-pt-pax-flags.patch
patching file bfd/elf-bfd.h
Hunk #1 succeeded at 1785 with fuzz 2 (offset 519 lines).
patching file bfd/elf.c
Hunk #1 succeeded at 1546 (offset 461 lines).
Hunk #2 succeeded at 3010 (offset 663 lines).
Hunk #3 succeeded at 4301 (offset 971 lines).
Hunk #4 succeeded at 4967 with fuzz 2 (offset 1013 lines).
Hunk #5 succeeded at 6488 (offset 1336 lines).
Hunk #6 succeeded at 6498 with fuzz 2 (offset 1336 lines).
patching file bfd/elflink.c
Hunk #1 succeeded at 5919 with fuzz 1 (offset 155 lines).
Hunk #2 succeeded at 5958 (offset 155 lines).
patching file binutils/readelf.c
Hunk #1 succeeded at 3779 (offset 1486 lines).
patching file include/bfdlink.h
Hunk #1 succeeded at 379 with fuzz 2 (offset 66 lines).
patching file include/elf/common.h
Hunk #1 succeeded at 465 (offset 42 lines).
Hunk #2 succeeded at 476 (offset 42 lines).
patching file ld/emultempl/elf32.em
Hunk #1 succeeded at 2565 with fuzz 1 (offset 426 lines).
patching file ld/ldgram.y
Hunk #1 succeeded at 1244 (offset 171 lines).
patching file ld/lexsup.c
Hunk #1 succeeded at 1819 (offset 26 lines).
applying patch /nix/store/jxhica5y04jd182c2b3xzap31ixxplw2-no-plugins.patch
patching file bfd/plugin.c
Hunk #1 succeeded at 334 (offset 1 line).
Hunk #2 succeeded at 366 (offset 1 line).
applying patch /nix/store/wilglaz00r3zpqy6j5awrzia446lzmk9-disambiguate-arm-targets.patch
patching file bfd/elf32-arm.c
applying patch /nix/store/pa83jbilxjpv5d4f62l3as4wg2fri7r7-always-search-rpath.patch
patching file ld/genscripts.sh
applying patch /nix/store/wlh3fqr3k9wrymvg83y3xi3dvqkwmca1-build-components-separately.patch
patching file bfd/configure.ac
patching file opcodes/Makefile.am
patching file opcodes/configure.ac
applying patch /nix/store/s3z9xjfl3ppms5m33j0pyrq07280l93c-bfd-1-disable-subdir-doc.patch
patching file bfd/Makefile.am
patching file bfd/Makefile.in
Hunk #1 succeeded at 371 (offset 32 lines).
@nix { "action": "setPhase", "phase": "autoreconfPhase" }
autoreconfPhase
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I . -I .. -I ../config
main::scan_file() called too early to check prototype at /nix/store/2zniw2qmqxzy5kjwxs5z79qyn3jkp3sv-automake-1.11.6/bin/.aclocal-wrapped line 644.
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '..'.
libtoolize: copying file '../ltmain.sh'
libtoolize: putting macros in '.'.
libtoolize: copying file './libtool.m4'
libtoolize: copying file './ltoptions.m4'
libtoolize: copying file './ltsugar.m4'
libtoolize: copying file './ltversion.m4'
libtoolize: copying file './lt~obsolete.m4'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
main::scan_file() called too early to check prototype at /nix/store/2zniw2qmqxzy5kjwxs5z79qyn3jkp3sv-automake-1.11.6/bin/.aclocal-wrapped line 644.
autoreconf: running: /nix/store/3hb5j83il656vpf9rzf014n0fln4f703-autoconf-2.64/bin/autoconf --force
autoreconf: running: /nix/store/3hb5j83il656vpf9rzf014n0fln4f703-autoconf-2.64/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /nix/store/2zniw2qmqxzy5kjwxs5z79qyn3jkp3sv-automake-1.11.6/bin/automake line 4159.
configure.ac:28: installing `../missing'
Makefile.am: installing `../depcomp'
autoreconf: Leaving directory `.'
@nix { "action": "setPhase", "phase": "configurePhase" }
configuring
configure flags: --disable-static --disable-dependency-tracking --prefix=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1 --bindir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/bin --sbindir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/sbin --includedir=/nix/store/48w6c91d47fhhpjp3s9165pxhiqlh0kk-libbfd-2.28.1-dev/include --oldincludedir=/nix/store/48w6c91d47fhhpjp3s9165pxhiqlh0kk-libbfd-2.28.1-dev/include --mandir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/share/man --infodir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/share/info --docdir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/share/doc/libbfd --libdir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/lib --libexecdir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/libexec --localedir=/nix/store/x4m3bfn4a16z5ym0s176lgdjz789mq30-libbfd-2.28.1/share/locale --enable-targets=all --enable-64-bit-bfd --enable-install-libbfd --enable-shared --with-system-zlib --build=x86_64-unknown-linux-musl --host=x86_64-unknown-linux-musl
checking build system type... Invalid configuration `x86_64-unknown-linux-musl': machine `x86_64-unknown-linux' not recognized
configure: error: /nix/store/qlyk4p97g9lc6dxwjkqb0ilbi0dm8lqv-bash-4.4-p12/bin/bash ./../config.sub x86_64-unknown-linux-musl failed

FYI, I just noticed that some of the new musl stuff won't build with gcc-7, e.g. https://hydra.nixos.org/build/69495411

AFAICT this happens on gcc6 as well, perhaps on all non-musl. Not sure there's much to be done about this, at least for now--I think @Ericson2314 has a PR that'd let us express that this is not meant for non-musl systems...?

dtzWill · Feb 19, 2018

FYI, I just noticed that some of the new musl stuff won't build with gcc-7, e.g. https://hydra.nixos.org/build/69495411

AFAICT this happens on gcc6 as well, perhaps on all non-musl. Not sure there's much to be done about this, at least for now--I think @Ericson2314 has a PR that'd let us express that this is not meant for non-musl systems...?

Oh, right, I looked wrong, into still-failing instead of newly-failing.

vcunat · Feb 19, 2018

Oh, right, I looked wrong, into still-failing instead of newly-failing.

I'm really not in favour of adding musl support to Nixpkgs. Adding support for non-standard libcs is a major undertaking. From my experience with dietlibc and klibc, it will require patches everywhere, which is maintenance nightmare, for no discernable advantage.

Since this is a major expansion of the scope of Nixpkgs, a decision on whether to add support for other libcs should really be done via the RFC process.

edolstra · Feb 19, 2018

I'm really not in favour of adding musl support to Nixpkgs. Adding support for non-standard libcs is a major undertaking. From my experience with dietlibc and klibc, it will require patches everywhere, which is maintenance nightmare, for no discernable advantage.

Since this is a major expansion of the scope of Nixpkgs, a decision on whether to add support for other libcs should really be done via the RFC process.

First pass at putting together an RFC for musl: NixOS/rfcs#23

WIP, looking for early feedback and any and all willing to serve as co-authors of the RFC.

dtzWill · Feb 20, 2018

First pass at putting together an RFC for musl: NixOS/rfcs#23

WIP, looking for early feedback and any and all willing to serve as co-authors of the RFC.

If nixpkgs rejects this SLNOS will happily adopt this patchset. Just sayin'.

oxij · Feb 20, 2018

If nixpkgs rejects this SLNOS will happily adopt this patchset. Just sayin'.

What is SNLOS, btw?

Ericson2314 · Feb 20, 2018

What is SNLOS, btw?

@Ericson2314 https://github.com/SLNOS/nixpkgs — a NixOS external branch with suckless.org influences

7c6f434c · Feb 20, 2018

@Ericson2314 https://github.com/SLNOS/nixpkgs — a NixOS external branch with suckless.org influences

https://github.com/SLNOS/nixpkgs — a NixOS external branch with suckless.org influences

But the public mirror is almost empty ATM as we are not a public fork (ATM). I regularly PR patches from SLNOS to nixpkgs (mostly mine, sometimes authored by others, see `git log --author "SLNOS" .` in nixpkgs). The only thing we regularly publish on that github page is the "no-bundle" fork of tor-browser nixpkgs currently uses for the "tor-browser from source" builds. You can read up on the mission in "The Church of Suckless NixOS is looking for followers" thread on ML from Fri, 17 Mar 2017 14:00:00 +0000 if you're interested. While musl support wasn't listed on TODO list from that thread it was implied there and it is on it explicitly right now. We want options for Alpine-like and sta.li-like SLNOS builds (eventually). FYI, ATM SLNOS provides * Gentoo-like use-flags for pkgs, * partial support for properly ccache-accelerated builds (nixpkgs' `ccacheStdenv` is broken and doesn't solve the main time waste on mass rebuilds: stdenv itself), * monoidal services for os, * bootloader management separated from os (you can have NixOS, SLNOS and, with some ugly hacking, GuixSD, all installed and bootable in parallel in a single nix-store), * partial support for s6 init, * a bunch of security- and privacy-oriented stuff, * (including no PulseAudio by default), * a bunch of other random crap. We are >400 patches and counting over master already, so adopting this tiny little branch is practically nothing.

oxij · Feb 20, 2018

https://github.com/SLNOS/nixpkgs — a NixOS external branch with suckless.org influences

But the public mirror is almost empty ATM as we are not a public fork (ATM). I regularly PR patches from SLNOS to nixpkgs (mostly mine, sometimes authored by others, see `git log --author "SLNOS" .` in nixpkgs). The only thing we regularly publish on that github page is the "no-bundle" fork of tor-browser nixpkgs currently uses for the "tor-browser from source" builds. You can read up on the mission in "The Church of Suckless NixOS is looking for followers" thread on ML from Fri, 17 Mar 2017 14:00:00 +0000 if you're interested. While musl support wasn't listed on TODO list from that thread it was implied there and it is on it explicitly right now. We want options for Alpine-like and sta.li-like SLNOS builds (eventually). FYI, ATM SLNOS provides * Gentoo-like use-flags for pkgs, * partial support for properly ccache-accelerated builds (nixpkgs' `ccacheStdenv` is broken and doesn't solve the main time waste on mass rebuilds: stdenv itself), * monoidal services for os, * bootloader management separated from os (you can have NixOS, SLNOS and, with some ugly hacking, GuixSD, all installed and bootable in parallel in a single nix-store), * partial support for s6 init, * a bunch of security- and privacy-oriented stuff, * (including no PulseAudio by default), * a bunch of other random crap. We are >400 patches and counting over master already, so adopting this tiny little branch is practically nothing.

@dtzWill hydra builds of musl-getconf and musl-getent have failed for a while on master and 18.03. Should we mark these as broken for 18.03 ?

xeji · Apr 5, 2018

@dtzWill hydra builds of musl-getconf and musl-getent have failed for a while on master and 18.03. Should we mark these as broken for 18.03 ?

Haha sorry, and no. They just are only meant to be used with a musl stdenv, where they work fine.

Should probably set meta.platforms appropriately, we couldn't do this before.

dtzWill · Apr 5, 2018

Haha sorry, and no. They just are only meant to be used with a musl stdenv, where they work fine.

Should probably set meta.platforms appropriately, we couldn't do this before.

#37337 will make meta.platforms work on 18.03 too, so we should merge that then.

Ericson2314 · Apr 5, 2018

#37337 will make meta.platforms work on 18.03 too, so we should merge that then.

matthewbauer · Apr 10, 2018

I didn't realize this was here! Really quick, would this work in Glibc as well? Ideally we'll want to use this for all Linuxes (see top-level/unix-tools.nix in staging).

Also could we get these directly from NetBSD? (I can make a PR for this)

Also could we get these directly from NetBSD? (I can make a PR for this)

Yes please!

matthewbauer · May 1, 2018

Can you open an issue in https://github.com/nixos/patchelf ?

Good call, just did! Thanks!

@dtzWill, why did you add libiconv to propagatedBuildInputs of SDL2 rather than to its buildInputs?

orivej · Jun 10, 2018

@dtzWill, why did you add libiconv to propagatedBuildInputs of SDL2 rather than to its buildInputs?

@orivej in my tree I found builds using SDL needed iconv so I figured it was supposed to be propagated (or "part of libc/stdenv"). Why, is this causing problems/unexpected?

dtzWill · Jun 10, 2018

@orivej in my tree I found builds using SDL needed iconv so I figured it was supposed to be propagated (or "part of libc/stdenv"). Why, is this causing problems/unexpected?

(I was using the full gnu libiconv, not what's available in musl which I think is what we're doing on master currently).

dtzWill · Jun 10, 2018

(I was using the full gnu libiconv, not what's available in musl which I think is what we're doing on master currently).

@dtzWill Can you explain a bit how to use this?

You have a "Quickstart with Binary Cache" section but I can't figure out what to configure in nix to actually use musl for everything.

nh2 · Jun 12, 2018

@dtzWill Can you explain a bit how to use this?

You have a "Quickstart with Binary Cache" section but I can't figure out what to configure in nix to actually use musl for everything.

@dtzWill I'm reworking SDL2 to fix #41620. It propagates many derivations that it should not, and one of those seems to be libiconv, so I asked to double check myself.

orivej · Jun 12, 2018

@dtzWill I'm reworking SDL2 to fix #41620. It propagates many derivations that it should not, and one of those seems to be libiconv, so I asked to double check myself.

Hey, just want to let you know that with the work in here I've managed to build some fully static Haskell executables! https://github.com/nh2/static-haskell-nix

nh2 · Jun 13, 2018

Hey, just want to let you know that with the work in here I've managed to build some fully static Haskell executables! https://github.com/nh2/static-haskell-nix

dtzWill requested review from Ericson2314, FRidh, nbp, orivej and zimbatm as code owners Feb 6, 2018

Ericson2314 added this to the 18.03 milestone Feb 6, 2018

Ericson2314 added 6.topic: cross-compilation 2.status: work-in-progress labels Feb 6, 2018

Ericson2314 referenced this pull request Feb 7, 2018
Closed
Remove cruft from platform descriptions #34274
3 of 3 tasks complete

dtzWill requested a review from edolstra as a code owner Feb 8, 2018

GrahamcOfBorg added 6.topic: emacs 6.topic: golang 6.topic: nixos 6.topic: python 6.topic: ruby 8.has: module (update) labels Feb 8, 2018

GrahamcOfBorg removed 6.topic: emacs 6.topic: nixos 8.has: module (update) labels Feb 8, 2018

dtzWill referenced this pull request Feb 11, 2018
Merged
lib/systems: musl "ABI"s, examples #34861
2 of 8 tasks complete

dtzWill referenced this pull request Feb 13, 2018
Closed
xz: set CONFIG_SHELL to /bin/sh, fix retained reference to bootstrap #34916
2 of 8 tasks complete

dtzWill added some commits Feb 13, 2018

nettle: cleanup cross changes
reviewer feedback + minor other things I noticed while revisiting.

Loading status checks…

6825c0c

cmake: don't force gcc, use more general cc/c++

Loading status checks…

e25a343

Ericson2314 added this to @bgamari's numerous fixes in Cross compilation Feb 13, 2018

Ericson2314 referenced this pull request Feb 14, 2018
Open
[RFC] A large batch of cross-compilation fixes #30882
0 of 8 tasks complete

dtzWill referenced this pull request Feb 19, 2018
Merged
llvmPackages_{4,5}: musl compat #35195
4 of 8 tasks complete

oxij referenced this pull request Mar 5, 2018
Open
[feature request] nixos/initrd-ssh: run a Tor hidden service #35900

This was referenced Mar 6, 2018

Merged

Misc fixups that may be of interest (don't merge as-is) matthewbauer/nix-bundle#28

Open

[WIP] [preview] Single static binary for Nix+deps (bash, coreutils, ...) via ALLVM NixOS/nix#1973

Ericson2314 referenced this pull request Apr 5, 2018
Merged
lib: Fix #30902 on 18.03 #37337
0 of 8 tasks complete

dtzWill referenced this pull request Apr 19, 2018
Open
Cross-compiling LLVM fails because llvm-tblgen must be run. #39170

nh2 referenced this pull request Jun 13, 2018
Closed
Fully static linking #6

NixOS/nixpkgs

Join GitHub today

musl-cross, native-musl, cross fixes, oh my! #34645

Conversation

Motivation for this change

PR History

TODO

Minor / Misc / Maybe

Quickstart with Binary Cache

Credits and Teasers: ALLVM

dtzWill requested review from Ericson2314, FRidh, nbp, orivej and zimbatm as code owners Feb 6, 2018

Ericson2314 reviewed Feb 6, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Ericson2314 added this to the 18.03 milestone Feb 6, 2018

Ericson2314 added 6.topic: cross-compilation 2.status: work-in-progress labels Feb 6, 2018

Ericson2314 referenced this pull request Feb 7, 2018

dtzWill requested a review from edolstra as a code owner Feb 8, 2018

GrahamcOfBorg added 6.topic: emacs 6.topic: golang 6.topic: nixos 6.topic: python 6.topic: ruby 8.has: module (update) labels Feb 8, 2018

Ericson2314 reviewed Feb 8, 2018 View changes

This comment has been minimized.

Ericson2314 Feb 8, 2018 • edited Edited 1 time Ericson2314 edited Feb 8, 2018 (most recent)

This comment has been minimized.

This comment has been minimized.

dtzWill commented Feb 8, 2018

GrahamcOfBorg removed 6.topic: emacs 6.topic: nixos 8.has: module (update) labels Feb 8, 2018

Mic92 reviewed Feb 9, 2018 View changes

This comment has been minimized.

This comment has been minimized.

dtzWill referenced this pull request Feb 11, 2018

danbst reviewed Feb 12, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

dtzWill commented Feb 13, 2018 • edited Edited 2 times dtzWill edited Feb 13, 2018 (most recent) dtzWill edited Feb 13, 2018

dtzWill referenced this pull request Feb 13, 2018

This comment has been minimized.

Systemd 237 w/musl: WIP, may fix in followup instead

dtzWill commented Feb 13, 2018 • edited Edited 1 time dtzWill edited Feb 13, 2018 (most recent)

Systemd 237 w/musl: WIP, may fix in followup instead

This comment has been minimized.

Mic92 commented Feb 13, 2018

dtzWill and others added some commits Feb 13, 2018

dtzWill added some commits Feb 13, 2018

Ericson2314 reviewed Feb 13, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

dtzWill added some commits Feb 13, 2018

Hide details View details Ericson2314 merged commit a267ae4 into NixOS:staging Feb 13, 2018 8 checks passed

8 checks passed

Ericson2314 added this to @bgamari's numerous fixes in Cross compilation Feb 13, 2018

This comment has been minimized.

dezgeg commented on pkgs/development/libraries/libbfd/default.nix in 767bddb Feb 13, 2018 • edited Edited 1 time dezgeg edited Feb 13, 2018 (most recent)

This comment has been minimized.

dtzWill replied Feb 13, 2018

Ericson2314 reviewed Feb 6, 2018

View changes

Ericson2314 reviewed Feb 8, 2018

View changes

Ericson2314 Feb 8, 2018 •

edited

Edited 1 time

Ericson2314 edited Feb 8, 2018 (most recent)

Mic92 reviewed Feb 9, 2018

View changes

danbst reviewed Feb 12, 2018

View changes

dtzWill commented Feb 13, 2018 •

edited

Edited 2 times

dtzWill edited Feb 13, 2018 (most recent)

dtzWill edited Feb 13, 2018

dtzWill commented Feb 13, 2018 •

edited

Edited 1 time

dtzWill edited Feb 13, 2018 (most recent)

Ericson2314 reviewed Feb 13, 2018

View changes

Ericson2314 merged commit `a267ae4` into NixOS:staging Feb 13, 2018
8 checks passed

dezgeg commented on `pkgs/development/libraries/libbfd/default.nix` in `767bddb` Feb 13, 2018 •

edited

Edited 1 time

dezgeg edited Feb 13, 2018 (most recent)