The Darwin patch was always supposed to be unconditional, and neither
of these patches should have any effect when applied to other targets.
Conditional application should be avoided where possible as it makes
it very easy to miss when a patch needs to be updated.
This was added in ebc2243778 ("binutils: Add iOS as a supported
platform"), at the same time as a patch. That patch was removed in
045c2d219d ("binutils-unwrapped: remove broken iOS patch"), and I'm
not sure what other reason there would be for autoreconfHook to be
required specifically for iOS, so I think we can remove it. It's not
possible to test since iOS cross has been broken for months, and
keeping this around is making other refactors (like adding cross
binutils packages) harder.
This hasn't made it past patchPhase since dde943e535 ("Revert
"Revert "Merge pull request #86954 from
lovesegfault/binutils-2.34"""), more than four ago. It's therefore
safe to say that nobody depends on this continuing to work in recent
Nixpkgs, and all these targetPlatform conditionals are making new
development (like adding cross binutils packages), so let's just
remove it.
It can be brought back if somebody wants to make it work in future,
but given that upstream binutils will continue to diverge from the
stagnant vc4 fork, a better way of doing this would be to upstream vc4
support to binutils, or at the very least use a different expression
for vc4 binutils.
This hasn't applied since e1ef521cff ("binutils: 2.39 -> 2.40"),
almost two years ago. It's therefore safe to say that nobody depends
on this continuing to work in recent Nixpkgs, and all these
targetPlatform conditionals are making new development (like adding
cross binutils packages), so let's just remove it.
It can be brought back if somebody wants to make it work in future,
but since it seems to just be trying to make iOS behave identically to
macOS, a better solution would probably be to just pass the darwin
triple when building for iOS.
Found with `fd \\.patch$ pkgs/ -x bash -c 'rg -F "{/}" pkgs/ -q || echo {}'``
We're running more and more into patches fetched via `applyPatches`, for the next PR i'll script something to account for that.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
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.
Without the change cross-compiling libbfd fails as:
GEN doc/bfdver.texi
CCLD doc/chew.stamp
...-bash-5.1-p16/bin/bash: line 1: gcc: command not found
Tested on `pkgsCross.riscv64.libbfd`.
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.
