musl service pack

[dvc94ch]

Motivation for this change

checked with readelf to make sure there isn't any leakage. (on all tested platforms)

0x0000000000000001 (NEEDED)             Shared library: [libc.so]
0x000000000000001d (RUNPATH)            Library runpath: [/nix/store/jxidsh8n95901m8i5yvzxxnk4azhqg2g-gcc-hello-0.0.1/lib64:/nix/store/jxidsh8n95901m8i5yvzxxnk4azhqg2g-gcc-hello-0.0.1/lib:/nix/store/wdk2l0n50qy1jy62i211b896hirfwrkb-libgcc-5.3.0/lib:/nix/store/16c974l1kqra3cr475gcgy2gsii45liq-musl-1.1.14/lib]

result/bin/hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/16c974l1kqra3cr475gcgy2gsii45liq-musl-1.1.14/lib/libc.so, not stripped

built and tested an arm-unknown-linux-musleabi cross toolchain (depends on #15867, gcc6)

built and tested a clang based toolchain, even the bsds still have a libgcc package. I think it should be it's own package. It's currently provided by the glibc package.

It appears I was reading outdated information, need to investigate the libgcc dependency further:
https://svnweb.freebsd.org/base?view=revision&revision=260849

clangWrapSelf = build: callPackage ../build-support/cc-wrapper {
    cc = build;
    isClang = true;
    stdenv = clangStdenv;
    libc = musl;
    extraPackages = [ libgcc libcxx libcxxabi ];
    nativeTools = false;
    nativeLibc = false;
  };

Things done

• Tested using sandboxing
  (nix.useSandbox on NixOS,
  or option build-use-sandbox in nix.conf
  on non-NixOS)
• Built on platform(s)
  • NixOS
  • OS X
  • Linux
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

[mention-bot]

By analyzing the blame information on this pull request, we identified @thoughtpolice, @wkennington and @edolstra to be potential reviewers

[dvc94ch]

So what is the deal with libgcc? Should it be a separate package, or should libgcc_s.so be copied to ${musl}/lib like in glibc?
(If someone is curious why libgcc_s is needed, this is what I found http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html)

[dvc94ch]

Also are linuxHeaders supposed to be included as part of the libc? Maybe having a package called base or something that depends on libgcc linuxHeaders and glibc would be good. So that if someone want's to use a different libc they can just override the libc without having to figure out how to include libgcc and linuxHeaders.

Also I think that the dynamic linker name should be an attribute of libc, so that we can move that logic out of build support. Probably moving libc specific configure flags out into the libc's might be a good idea, and if there aren't any either complain it's an unsupported combination of libc/compiler. To modularize our toolchain/libc options/combinations, we should specify some sort of interface for the various components, maybe starting with libc.

Does someone have some thoughts on this stuff?

[bjornfor]

@dvc94ch: Sounds like a good idea to me.

[joachifm]

Who needs to sign off on this to get it integrated (ignoring the current merge conflict)?

[dvc94ch]

It actually breaks the bootstrap tools, haven't looked into why...
On Jul 26, 2016 11:25 AM, "Joachim F." [email protected] wrote:

Who needs to sign off on this to get it integrated (ignoring the current
merge conflict)?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16217 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAtRryZdujp36PSVH6WuritDy9ApGrvVks5qZdJ5gaJpZM4I0qZY
.

[dtzWill]

What do you mean it breaks the bootstrap tools? Can you point to a build failure or something for investigation? If nothing else I've been building on this so am interested in any known issues :). Thanks!

[dvc94ch]

Awesome to hear!! Here I make a change to bootstrap tools to use the gcc-musl toolchain instead of the musl gcc wrapper. If memory servers me correctly nix-build .../make-bootstrap-tools.nix errors. I think it was related to the linux-headers and libgcc, but it's been a while...

[dtzWill]

Ah, okay. Well as a local kludge I added the linux headers to musl like glibc/uclibc do:

commit 426994ad67ae1faf8cb710c1fb667b2676343658
Author: Will Dietz <[email protected]>
Date:   Tue Jul 12 08:14:39 2016 -0500

    Add linux headers to musl so we can build things like libunwind.

diff --git a/pkgs/os-specific/linux/musl/default.nix b/pkgs/os-specific/linux/musl/default.nix
index ba62652..665a504 100644
--- a/pkgs/os-specific/linux/musl/default.nix
+++ b/pkgs/os-specific/linux/musl/default.nix
@@ -1,4 +1,4 @@
-{ stdenv, fetchurl, cross ? null, gccCross ? null }:
+{ stdenv, fetchurl, cross ? null, gccCross ? null, linuxHeaders }:

 stdenv.mkDerivation rec {
   name    = "musl-${version}${stdenv.lib.optionalString (cross != null) ''-${cross.arch}''}";
@@ -30,6 +30,12 @@ stdenv.mkDerivation rec {
   dontStrip = true;
   dontCrossStrip = true;

+  postInstall = ''
+    # Make linux headers available to users of this libc.
+    # Not sure why, but link in all but scsi directory as that's what uclibc/glibc do.
+    (cd $dev/include && ln -s $(ls -d ${linuxHeaders}/include/* | grep -v "scsi$") .)
+  '';
+
   passthru = {
     # isMusl can be dropped when/if providing the dynamicLinker
     # name through the libc is adopted

Unfortunately my tree is a bit of a mess so rebase'ing bits or generally separating from my own changes will take some time 😇 .

[dvc94ch]

Thank you for picking up the ball ;-)

[dtzWill]

Haha, well I'll see what I can do and will of course give you appropriate attribution if I end up being the one wrapping this up 👍 .

Anyway, pushed a few related commits here:

https://github.com/dtzWill/nixpkgs/commits/musl_misc_commits

Lots of package fixes too but those will take more time and probably need some testing and review :).

[Mic92]

@dtzWill are you going to create a new pull request regarding this?

[dvc94ch]

I'll close this then, @dtzWill can open a new PR...