with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
Without the change `pkgsMusl.pkgsStatic.buildPackages.binutils.bintools`
build fails as:
$ ln: failed to create symbolic link './include': File exists
This happens because both host and target are `x86_64-unknown-linux-musl`.
But `hostPlatform` differs from `targetPlatform` by `isStatic` value.
By `./configure`'s standard it's not yet a cross-compilation. The change
tries to move things around only when tuples change.
binutils plugins API does not depend on target. It depends only on host.
Tested the change to still be able to compile `firefox` which uses wasi
target and pulls in llvm with binutils plugin support.
`binutils` is inconsistent at installing it's headers to
$dev/include
Instead it installs headers into two locations:
$out/$host/$target/include
$dev/include
There is no distinction between these two. Both headers are for HOST
libraries. Expetially for multitarget binutils builds.
This change fixes build of the following packages that build `binutils`
as a cross-compiler:
pkgsCross.x86_64-freebsd.buildPackages.llvm_12
pkgsCross.aarch64-multiplatform.buildPackages.llvm_12
I got the plugin API support at least once incorrect. Instead of
copying the deifnition let's consolidate it within binutils itself.
While at it forward-ported changes to llvm_{13,14,15}.
The change is a no-op from rebuild perspective.
A few potentially disruptive changes:
- binutils does not embed ${binutils-unwrapped}/lib as a default library
search path anymore. This will cause link failures for -lbfd -lopcodes
users that did not declare their dependency on those libraries. They
will need to add `libbfd` and `libopcodes` attributes to build inputs.
- `libbfd` and `libopcodes` attributes now just reference
`binutils-unwrapped.{dev,lib}` pair of attributes without patching
`binutils` build system.
We don't patch build system anymore and use multiple outputs out of
existing `binutils` build. That makes the result more maintainable: no
need to handle ever growing list of dependencied of `libbfd`. This time
new addition was `libsframe`.
To accomodate `out` / `lib` output split I had to remove `lib` -> `bin`
backreference by removing legacy lookup path for plugins.
I also did not enable `zstd` just yet as `nixpkgs` version of `zstd`
package pulls in `cmake` into bootstrap sequence.
Changes: https://lists.gnu.org/archive/html/info-gnu/2023-01/msg00003.html
Normally binutils provides pregenerated manuals along with release
tarball. Manuals regeneration is needed every time we change
`configure.ac`. But usually there are no material changes in it.
This change instead inhibits manuals regeenration by keeping
man and info files up to date.
The diff of bootstrap tree before and after the change:
$ nix-store --query --graph $(nix-instantiate -A stdenv) |
fgrep ' -> ' | awk '{print $3}' | sort -u |
sed 's/"[0-9a-z]\{32\}-/"/g' | sort > before
$ nix-store --query --graph $(nix-instantiate -A stdenv) |
fgrep ' -> ' | awk '{print $3}' | sort -u |
sed 's/"[0-9a-z]\{32\}-/"/g' | sort > after
$ diff -U0 before after
--- before
+++ after
@@ -100 +99,0 @@
-"texinfo-6.8.drv"
Co-authored-by: Adam Joseph <54836058+amjoseph-nixpkgs@users.noreply.github.com>
This reverts commit b3640e024f.
When applied, the patch causes some dynamic relocations to be missing,
even in cases where they are clearly needed.
This causes bugs such as https://github.com/NixOS/nixpkgs/issues/107386
where `fprintf(stderr, ...)` segfaults because the stderr relocation was
not added.
The change restores the patch `nixpkgs` kept for `binutils-2.38`.
On top of that we revert the second `binutils-2.39`-specific commit
that attempted to fix it.
We can drop both reverts once https://sourceware.org/PR29547 is fixed.
Before the change 'postFixup' was breaking binaries as it deleted `libctf.so`'s
dependency without fixing the links (https://hydra.nixos.org/build/173957444):
objdump:
symbol lookup error: ...-binutils-2.38/lib/libctf.so.0: undefined symbol: htab_eq_string
Instead of tying binutils and libbfd together let's stop replacing the
libraries and use local copies. They are not mechanically interchangeable.
Ideally binutils' upstream build system should allow linking external
`libbfd`/`libopcodes`/`libctf` but we are not there yet.
Upstream binutils is missing sensible defaults for a few flags
(notably linker personality) when cross-compiling to
mips64el-*-*abi64.
Most of the time this isn't an issue because packages that invoke the
linker directly detect the flags from gcc's behavior (for example,
libtool does this) and gcc has good code for detecting the right
defaults. However some do not; notably nix, itself lacks this.
Presumably Debian is working on upstreaming this, and has more clout
than we do. I propose we carry their patch in the meantime. The
patch is conditioned on stdenv.targetPlatform.isMips64n64 in order to
avoid mass-rebuilds.
Closes#164835.
ld.gold is “A new, faster, ELF only linker”. Thus we only should pass
the configure flag --with-gold if our target platform will actually
support gold (in which case binutil's configure script silently
disables it).
With this change, not only will configureFlags represent the actual
configuration more closely, but we can also expose if the binutils
derivation contains ld.gold via a passthru attr. Specifically this
means that:
nix-repl> pkgsCross.mingwW64.stdenv.cc.bintools.bintools.hasGold
false
The intended way to use this is to check
`stdenv.cc.bintools.bintools or false` which returns accurate results
regardless of the actual linker derivation.
TODO: maybe also add hasGold to binutils wrapper as it also symlinks
ld.gold in?
