mold: wrap with ld-wrapper

[tobim]

Description of changes

Wrapping mold so it can find libraries from the nix build environment.

See #24744 for additional context. The situation with lld is very similar, but mold was easier to fix.

Demo:

$ printf '#include <iostream>\nint main(){std::cout << "Woo!\\\n";}\n' \
  | c++ -B$(nix build --print-out-paths .#mold)/bin -x c++ - \
  && readelf -p .comment a.out \
  && ./a.out

String dump of section '.comment':
  [     0]  GCC: (GNU) 10.3.0
  [    12]  mold 1.2.1 (compatible with GNU ld)
  [    37]  GCC: (GNU) 8.3.0

Woo!

• check in a nix-shell with additional dependencies

• verify that this doesn't involuntarily break linking when used with rust

• Built on platform(s)

  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin

• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)

• Tested, as applicable:

  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages

• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage

• Tested basic functionality of all binary files (usually in ./result/bin/)

• 22.05 Release Notes (or backporting 21.11 Release notes)

  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

• Fits CONTRIBUTING.md.

[cmm]

would be totally neat if this got merged

[a-kenji]

I tested the following under x86_64-linux:

• check in a nix-shell with additional dependencies
• verify that this doesn't involuntarily break linking when used with rust: I can't verify that, but I tested it with various projects that link with shared libraries (sqlite3, openssl, gtk, adwaita) and it worked flawlessly in my tests.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/1100

[SuperSandro2000]

Why not use wrapProgram or makeWrapper?

[tobim]

i don't understand how those tools would help solve the problem in a better way.

[Mic92]

I don't think this would help here.

[sternenseemann]

Linkers in nixpkgs are left unwrapped intentionally – our wrapper scripts are quite invasive and we want users to be able to deal with more low-level situations manually as well – outside of stdenv the wrapper scripts are useless anyways.

Therefore, you work should be split into mold and mold-unwrapped or similar. Additionally, the wrapped version should probably utilise wrapBintools (not sure where to pull the other bintools from best, maybe llvm?), so it can be used in a custom stdenv.

[RaitoBezarius]

Can I help to get this merged?

[tobim]

I don't have any capacity to work on this at the moment. Fell free to open a new PR and work in the suggestions from @sternenseemann.

[lf-]

@RaitoBezarius I've poked at using wrapBintools for this for a proof of concept for work. One big issue with it is that it's less than helpful on macOS without some patching. Further, it's hard to test since changing the original file will be a world rebuild. We should possibly introduce a new parameter to it or use a postInstall hook or something to work around this issue.

{ mold
, stdenv
, libcCross
, callPackage
, darwin
}:
let wrapBintoolsWith2 =
  { bintools
  , libc ? if stdenv.targetPlatform != stdenv.hostPlatform then libcCross else stdenv.cc.libc
  , ...
  } @ extraArgs:
  callPackage ./pkgs/build-support/bintools-wrapper2 (
    let self = {
      nativeTools = stdenv.targetPlatform == stdenv.hostPlatform && stdenv.cc.nativeTools or false;
      nativeLibc = stdenv.targetPlatform == stdenv.hostPlatform && stdenv.cc.nativeLibc or false;
      nativePrefix = stdenv.cc.nativePrefix or "";

      noLibc = (self.libc == null);

      inherit bintools libc;
      inherit (darwin) postLinkSignHook signingUtils;
    } // extraArgs; in self
  );
in
wrapBintoolsWith2 {
  bintools = mold;
}

I've patched binutils-wrapper2/default.nix like so:

      # added ld.mold ld64.mold
      for variant in ld.gold ld.bfd ld.lld ld.mold ld64.mold; do
        local underlying=$ldPath/${targetPrefix}$variant
        [[ -e "$underlying" ]] || continue
        wrap ${targetPrefix}$variant ${./ld-wrapper.sh} $underlying
      done

[lf-]

Here is the updated self contained version of the hack that people can vendor (don't use path if you're in nixpkgs). But the problem I have now is that there is pervasive assumption throughout the scripts that ld is the platform-specific linker; that is, ${mold}/bin/ld is ld64.mold.

 » clang -fuse-ld=mold test.c                    
mold: fatal: unknown command line option: -z
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)

The wrapper injected that flag because it was supported on the ELF targeting one, which is wrong. Cause:
https://github.com/nixos/nixpkgs/blob/549e08c8e8a0e79952227c3300702d3d0fbb71a8/pkgs/build-support/bintools-wrapper/default.nix#L272-L281

# Kinda evil wrapper for mold to get all the nix flags but whatever, it works
{ mold
, wrapBintoolsWith
, path
}:
(wrapBintoolsWith {
  bintools = mold;
}).overrideAttrs (old: {
  # for baffling reasons postInstall is not getting run. no idea, buddy.
  installPhase = old.installPhase + ''
      for variant in ld.mold ld64.mold; do
        # XXX: probably broken with cross compilation, w/e
        local underlying=$ldPath/$variant
        [[ -e "$underlying" ]] || continue
        wrap $variant ${path}/pkgs/build-support/bintools-wrapper/ld-wrapper.sh $underlying
      done
  '';
})

[lf-]

fyi: on Linux you don't need any of that override stuff, and I think that Linux-only is an ok starting point for now!

[9999years]

Anything blocking this?

[Artturin]

adding mold to the variant list #216383

@lf- postInstall isn't being run because you're overriding installPhase and not using runHook postInstall

[Artturin]

i think #216383 replaces the need for this pr