BoomMicrophone/nixpkgs-suyu
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
nixpkgs-suyu/pkgs/development/libraries/libbfd/default.nix

62 lines
1.8 KiB
Nix
Raw Normal View History

libiberty, libbfd: Make hash less fickle These shouldn't respond to targetPlatform, but previously did. The reason is somewhat complex: they would rely on the sources of gcc and binutils, respectively, which *do* depend on the target platform. Obviously the source is the same in all cases, but when those packages are no longer preserved from bootstrapping stages their `src` attributes use a different fetchurl resulting in a changed hash.
2018-02-21 03:27:57 +01:00
{ stdenv, buildPackages
, fetchurl, fetchpatch, gnu-config, autoreconfHook264, bison
bfd, opcodes: Init separate derivations for binutils libraries On most distros, these are just built and distributed as part of binutils. We don't use binutils across the board, however, but rather switch between binutils and a cctools-binutils mashup, and change the outputs on binutils too. This creates a combinatorial conditional soup which is hard to maintain. My hope is to lower the the state space. While my patch isn't the most maintainable, they make downstream packages become more maintainable to compensate. The additional derivations themselves are completely platform-agnostic, always they always supports all possible target platforms, and always yield "out" and "dev" outputs. That, in turn, allows downstream packages to not worry about a dependency shape-shifting under them. In fact, the actual binutils package can avoid needing multiple outputs now that these serve the requisite libraries, so that also can become simpler on all platforms, too, removing the original wart this PR circumnavigates for now. Actually changing the binutils package to leverage is a mass rebuild, however, so I'll leave that for a separate PR. I do hope to upstream something like my patch too, but until then I'll make myself maintainer of these derivations
2017-10-11 00:48:42 +02:00
, libiberty, zlib
}:
libiberty, libbfd: Make hash less fickle These shouldn't respond to targetPlatform, but previously did. The reason is somewhat complex: they would rely on the sources of gcc and binutils, respectively, which *do* depend on the target platform. Obviously the source is the same in all cases, but when those packages are no longer preserved from bootstrapping stages their `src` attributes use a different fetchurl resulting in a changed hash.
2018-02-21 03:27:57 +01:00
let inherit (buildPackages.buildPackages) binutils-raw; in
bfd, opcodes: Init separate derivations for binutils libraries On most distros, these are just built and distributed as part of binutils. We don't use binutils across the board, however, but rather switch between binutils and a cctools-binutils mashup, and change the outputs on binutils too. This creates a combinatorial conditional soup which is hard to maintain. My hope is to lower the the state space. While my patch isn't the most maintainable, they make downstream packages become more maintainable to compensate. The additional derivations themselves are completely platform-agnostic, always they always supports all possible target platforms, and always yield "out" and "dev" outputs. That, in turn, allows downstream packages to not worry about a dependency shape-shifting under them. In fact, the actual binutils package can avoid needing multiple outputs now that these serve the requisite libraries, so that also can become simpler on all platforms, too, removing the original wart this PR circumnavigates for now. Actually changing the binutils package to leverage is a mass rebuild, however, so I'll leave that for a separate PR. I do hope to upstream something like my patch too, but until then I'll make myself maintainer of these derivations
2017-10-11 00:48:42 +02:00
stdenv.mkDerivation rec {
name = "libbfd-${version}";
bintools-wrapper: Import separately from cc-wrapper
2017-08-26 17:43:30 +02:00
inherit (binutils-raw.bintools) version src;
bfd, opcodes: Init separate derivations for binutils libraries On most distros, these are just built and distributed as part of binutils. We don't use binutils across the board, however, but rather switch between binutils and a cctools-binutils mashup, and change the outputs on binutils too. This creates a combinatorial conditional soup which is hard to maintain. My hope is to lower the the state space. While my patch isn't the most maintainable, they make downstream packages become more maintainable to compensate. The additional derivations themselves are completely platform-agnostic, always they always supports all possible target platforms, and always yield "out" and "dev" outputs. That, in turn, allows downstream packages to not worry about a dependency shape-shifting under them. In fact, the actual binutils package can avoid needing multiple outputs now that these serve the requisite libraries, so that also can become simpler on all platforms, too, removing the original wart this PR circumnavigates for now. Actually changing the binutils package to leverage is a mass rebuild, however, so I'll leave that for a separate PR. I do hope to upstream something like my patch too, but until then I'll make myself maintainer of these derivations
2017-10-11 00:48:42 +02:00
outputs = [ "out" "dev" ];
bintools-wrapper: Import separately from cc-wrapper
2017-08-26 17:43:30 +02:00
patches = binutils-raw.bintools.patches ++ [
bfd, opcodes: Init separate derivations for binutils libraries On most distros, these are just built and distributed as part of binutils. We don't use binutils across the board, however, but rather switch between binutils and a cctools-binutils mashup, and change the outputs on binutils too. This creates a combinatorial conditional soup which is hard to maintain. My hope is to lower the the state space. While my patch isn't the most maintainable, they make downstream packages become more maintainable to compensate. The additional derivations themselves are completely platform-agnostic, always they always supports all possible target platforms, and always yield "out" and "dev" outputs. That, in turn, allows downstream packages to not worry about a dependency shape-shifting under them. In fact, the actual binutils package can avoid needing multiple outputs now that these serve the requisite libraries, so that also can become simpler on all platforms, too, removing the original wart this PR circumnavigates for now. Actually changing the binutils package to leverage is a mass rebuild, however, so I'll leave that for a separate PR. I do hope to upstream something like my patch too, but until then I'll make myself maintainer of these derivations
2017-10-11 00:48:42 +02:00
../../tools/misc/binutils/build-components-separately.patch
libbfd: fix for cross (based on same from @bgamari)
2018-01-11 01:07:20 +01:00
(fetchpatch {
url = "https://raw.githubusercontent.com/mxe/mxe/e1d4c144ee1994f70f86cf7fd8168fe69bd629c6/src/bfd-1-disable-subdir-doc.patch";
sha256 = "0pzb3i74d1r7lhjan376h59a7kirw15j7swwm8pz3zy9lkdqkj6q";
})
bfd, opcodes: Init separate derivations for binutils libraries On most distros, these are just built and distributed as part of binutils. We don't use binutils across the board, however, but rather switch between binutils and a cctools-binutils mashup, and change the outputs on binutils too. This creates a combinatorial conditional soup which is hard to maintain. My hope is to lower the the state space. While my patch isn't the most maintainable, they make downstream packages become more maintainable to compensate. The additional derivations themselves are completely platform-agnostic, always they always supports all possible target platforms, and always yield "out" and "dev" outputs. That, in turn, allows downstream packages to not worry about a dependency shape-shifting under them. In fact, the actual binutils package can avoid needing multiple outputs now that these serve the requisite libraries, so that also can become simpler on all platforms, too, removing the original wart this PR circumnavigates for now. Actually changing the binutils package to leverage is a mass rebuild, however, so I'll leave that for a separate PR. I do hope to upstream something like my patch too, but until then I'll make myself maintainer of these derivations
2017-10-11 00:48:42 +02:00
];
# We just want to build libbfd
libbfd: back to postPatch, restore configurePlatforms
2018-02-13 20:19:47 +01:00
postPatch = ''
bfd, opcodes: Init separate derivations for binutils libraries On most distros, these are just built and distributed as part of binutils. We don't use binutils across the board, however, but rather switch between binutils and a cctools-binutils mashup, and change the outputs on binutils too. This creates a combinatorial conditional soup which is hard to maintain. My hope is to lower the the state space. While my patch isn't the most maintainable, they make downstream packages become more maintainable to compensate. The additional derivations themselves are completely platform-agnostic, always they always supports all possible target platforms, and always yield "out" and "dev" outputs. That, in turn, allows downstream packages to not worry about a dependency shape-shifting under them. In fact, the actual binutils package can avoid needing multiple outputs now that these serve the requisite libraries, so that also can become simpler on all platforms, too, removing the original wart this PR circumnavigates for now. Actually changing the binutils package to leverage is a mass rebuild, however, so I'll leave that for a separate PR. I do hope to upstream something like my patch too, but until then I'll make myself maintainer of these derivations
2017-10-11 00:48:42 +02:00
cd bfd
'';
libbfd: manually update config.guess/config.sub Workaround for building "from" the bfd directory but needing to update files a level above. This needs to be done *after* autoreconf since autoreconf will replace these itself, apparently.
2018-02-13 20:39:42 +01:00
postAutoreconf = ''
echo "Updating config.guess and config.sub from ${gnu-config}"
cp -f ${gnu-config}/config.{guess,sub} ../
'';
# We update these ourselves
dontUpdateAutotoolsGnuConfigScripts = true;
bfd, opcodes: Init separate derivations for binutils libraries On most distros, these are just built and distributed as part of binutils. We don't use binutils across the board, however, but rather switch between binutils and a cctools-binutils mashup, and change the outputs on binutils too. This creates a combinatorial conditional soup which is hard to maintain. My hope is to lower the the state space. While my patch isn't the most maintainable, they make downstream packages become more maintainable to compensate. The additional derivations themselves are completely platform-agnostic, always they always supports all possible target platforms, and always yield "out" and "dev" outputs. That, in turn, allows downstream packages to not worry about a dependency shape-shifting under them. In fact, the actual binutils package can avoid needing multiple outputs now that these serve the requisite libraries, so that also can become simpler on all platforms, too, removing the original wart this PR circumnavigates for now. Actually changing the binutils package to leverage is a mass rebuild, however, so I'll leave that for a separate PR. I do hope to upstream something like my patch too, but until then I'll make myself maintainer of these derivations
2017-10-11 00:48:42 +02:00
nativeBuildInputs = [ autoreconfHook264 bison ];
buildInputs = [ libiberty zlib ];
libbfd: back to postPatch, restore configurePlatforms
2018-02-13 20:19:47 +01:00
configurePlatforms = [ "build" "host" ];
bfd, opcodes: Init separate derivations for binutils libraries On most distros, these are just built and distributed as part of binutils. We don't use binutils across the board, however, but rather switch between binutils and a cctools-binutils mashup, and change the outputs on binutils too. This creates a combinatorial conditional soup which is hard to maintain. My hope is to lower the the state space. While my patch isn't the most maintainable, they make downstream packages become more maintainable to compensate. The additional derivations themselves are completely platform-agnostic, always they always supports all possible target platforms, and always yield "out" and "dev" outputs. That, in turn, allows downstream packages to not worry about a dependency shape-shifting under them. In fact, the actual binutils package can avoid needing multiple outputs now that these serve the requisite libraries, so that also can become simpler on all platforms, too, removing the original wart this PR circumnavigates for now. Actually changing the binutils package to leverage is a mass rebuild, however, so I'll leave that for a separate PR. I do hope to upstream something like my patch too, but until then I'll make myself maintainer of these derivations
2017-10-11 00:48:42 +02:00
configureFlags = [
"--enable-targets=all" "--enable-64-bit-bfd"
"--enable-install-libbfd"
"--enable-shared"
"--with-system-zlib"
];
enableParallelBuilding = true;
meta = with stdenv.lib; {
description = "A library for manipulating containers of machine code";
longDescription = ''
BFD is a library which provides a single interface to read and write
object files, executables, archive files, and core files in any format.
It is associated with GNU Binutils, and elsewhere often distributed with
it.
'';
homepage = http://www.gnu.org/software/binutils/;
license = licenses.gpl3Plus;
maintainers = with maintainers; [ ericson2314 ];
platforms = platforms.unix;
};
}
Reference in a new issue Copy permalink