LLD linker does not have required nixpkgs wrapper script and flags

[nh2]

Currently using the lld linker in nix doesn't work correctly.

Executables that it produces have entries in lld being not found (rpaths are missing).

That's because ld and gold have wrappers that do the following:

nixpkgs/pkgs/build-support/cc-wrapper/ld-wrapper.sh

Line 133 in 593b46f

# Second, for each directory in the library search path (-L...),

 # First, find all -L... switches.

    # Second, for each directory in the library search path (-L...),
    # see if it contains a dynamic library used by a -l... flag.  If
    # so, add the directory to the rpath.

But lld currently doesn't have such a wrapper.

(I found this via See also #24692 (comment).)

Also this type of patch or setting to --enable-new-dtags will likely be needed, and potentially other changes nixpkgs makes to ld and gold.

[domenkozar]

This would be a nice addition to speed up Haskell builds by reducing time in linking phase.

[taktoa]

As part of my work this summer on speeding up Nix Haskell builds for Awake Networks, I'm interested in tackling this issue (and upstreaming a fix). Does it just amount to adding something similar to the code snippet below to pkgs/build-support/cc-wrapper/default.nix (around line 180)?

      if [ -e ${binutils_bin}/bin/ld.gold ]; then
        wrap ld.gold ${./ld-wrapper.sh} ${binutils_bin}/bin/ld.gold
      fi

or should I be modifying the lld package itself to use the ld-wrapper.sh script?
Also, if someone could cook up an example Nix expression that should build iff I have correctly wrapped lld, that would be quite useful in implementing a fix for this.

[nh2]

@taktoa I can't answer conclusively, but I suspect it won't be as trivial as using the exiting scripts.

The right approach is likely to first do a proper reads through all things nixpkgs does to ld or gold, and then check which of those have to be done to lld as well.

For example, I know that lld searches through some default paths. We probably want to patch them out, or pass flags so that it doesn't do that.

[domenkozar]

@taktoa we're interested in this project at https://github.com/input-output-hk as well - maybe we could have quick chat and join some forces :)

we invested a bit of time into parallel GC and general GHC option tuning for scaling the compilation into multiple cores: https://github.com/input-output-hk/iohk-nixops/pull/49/files

Indeed linking takes a hell lot of time, but buildTarget fix in Cabal master will help a lot, limiting what executables are built for the given package.

[domenkozar]

@taktoa for this particular change, I'd talk to @vcunat or @wkennington

[vcunat]

Assuming the relevant linker options have the same syntax, I'd expect that the same wrapping approach should work. The way cc-wrapper is written now, I'd suggest to first try adding an option that makes it include ld.lld. (And maybe an option to make it the default ld, though I don't know if that's the standard way to exchange linkers.)

[matthewbauer]

I have now added the lldClang stdenv. We could expose this better as needed if people want lld to be installable. Otherwise, without anything actionable I think this can be closed?

for instance, you can run llvm linker:

with import <nixpkgs> { system = "x86_64-linux"; };
let stdenv' = overrideCC stdenv llvmPackages_8.lldClang;
in stdenv'.mkDerivation {
  name = "test";
  buildCommand = ''
  cc ${./test.c} -o test
  ./test
  '';
}

Also install lld using:

nix-env -iA nixpkgs.llvmPackages_8.lldClang.bintools

[nh2]

Otherwise, without anything actionable I think this can be closed?

@matthewbauer The actionable part from the issue description was:

Executables that it produces have entries in lld being not found (rpaths are missing).
But lld currently doesn't have such a wrapper [that fixes the rpaths].

Concretely, we want to be able to:

• Use a nix-provided lld in nix-build and nix-shell to link executables, also on non-NixOS platforms like Ubuntu
  • nix-shell support means it should work without sandbox, without lld picking up some global paths that it has hardcoded; it should be patched or wrapped to not do that, like binutils ld is
• Use lld for general nix builds of specific or all packages (lddClang sounds like it does exactly that)

If your lldClang env fixes all those points, then this can be closed; if it does not fix/wrap/patch lld so that the nix-shell-on-Ubuntu use case works, then we still have to do that.

[domenkozar]

Can't easily override stdenv in haskell #66267, but could be checked by overriding it in nixpkgs and see if darwin builds.