2018-07-21 02:44:44 +02:00
|
|
|
{ stdenv
|
|
|
|
|
, fetchpatch, gnu-config, autoreconfHook264, bison, binutils-unwrapped
|
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
|
|
|
|
|
}:
|
|
|
|
|
|
|
|
|
|
stdenv.mkDerivation rec {
|
|
|
|
|
name = "libbfd-${version}";
|
2018-04-03 18:50:25 +02:00
|
|
|
inherit (binutils-unwrapped) 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" ];
|
|
|
|
|
|
2018-04-03 18:50:25 +02:00
|
|
|
patches = binutils-unwrapped.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
|
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
|
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
|
|
|
|
|
'';
|
|
|
|
|
|
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 ];
|
|
|
|
|
|
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.
|
|
|
|
|
'';
|
2018-12-01 19:22:13 +01:00
|
|
|
homepage = https://www.gnu.org/software/binutils/;
|
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
|
|
|
license = licenses.gpl3Plus;
|
|
|
|
|
maintainers = with maintainers; [ ericson2314 ];
|
|
|
|
|
platforms = platforms.unix;
|
|
|
|
|
};
|
|
|
|
|
}
|