nixpkgs/pkgs/os-specific/darwin/binutils/default.nix
John Ericson adaa110a72 binutils: No more darwin conditionals
Since at least d7bddc27b23da8ce7bc19cfeeeb0cbebdb5a4410, we've had a
situation where one should depend on:

 - `stdenv.cc.bintools`: for executables at build time
 - `libbfd` or `libiberty`: for those libraries
 - `targetPackages.cc.bintools`: for exectuables at *run* time
 - `binutils`: only for specifically GNU Binutils's executables,
   regardless of the host platform, at run time.

and that commit cleaned up this usage to reflect that. This PR flips the
switch so that:

 - `binutils` is indeed unconditionally GNU Binutils
 - `binutils-raw`, which previously served that role, is gone.

so that the correct usage will be enforced going forward and everything
is simple.

N.B. In a few cases `binutils-unwrapped` (which before and now was
unconditionally actual GNU binutils), rather than `binutils` was used to
replace old `binutils-raw` as it is friendly towards some cross
compilation usage by avoiding a reference to the next bootstrapping
change.
2018-04-03 13:34:52 -04:00

57 lines
1.9 KiB
Nix

{ stdenv, binutils-unwrapped, cctools
, hostPlatform, targetPlatform
}:
# Make sure both underlying packages claim to have prepended their binaries
# with the same targetPrefix.
assert binutils-unwrapped.targetPrefix == cctools.targetPrefix;
let
inherit (binutils-unwrapped) targetPrefix;
cmds = [
"ar" "ranlib" "as" "dsymutil" "install_name_tool"
"ld" "strip" "otool" "lipo" "nm" "strings" "size"
];
in
# TODO loop over targetPrefixed binaries too
stdenv.mkDerivation {
name = "${targetPrefix}cctools-binutils-darwin";
outputs = [ "out" "info" "man" ];
buildCommand = ''
mkdir -p $out/bin $out/include
ln -s ${binutils-unwrapped.out}/bin/${targetPrefix}c++filt $out/bin/${targetPrefix}c++filt
# We specifically need:
# - ld: binutils doesn't provide it on darwin
# - as: as above
# - ar: the binutils one prodices .a files that the cctools ld doesn't like
# - ranlib: for compatibility with ar
# - dsymutil: soon going away once it goes into LLVM (this one is fake anyway)
# - otool: we use it for some of our name mangling
# - install_name_tool: we use it to rewrite stuff in our bootstrap tools
# - strip: the binutils one seems to break mach-o files
# - lipo: gcc build assumes it exists
# - nm: the gnu one doesn't understand many new load commands
for i in ${stdenv.lib.concatStringsSep " " (builtins.map (e: targetPrefix + e) cmds)}; do
ln -sf "${cctools}/bin/$i" "$out/bin/$i"
done
ln -s ${binutils-unwrapped.out}/share $out/share
ln -s ${cctools}/libexec $out/libexec
mkdir -p "$info/nix-support" "$man/nix-support"
printWords ${binutils-unwrapped.info} \
>> $info/nix-support/propagated-build-inputs
# FIXME: cctools missing man pages
printWords ${binutils-unwrapped.man} \
>> $man/nix-support/propagated-build-inputs
'';
passthru = {
inherit targetPrefix;
};
}