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
The problem was initially noticed in https://sourceware.org/PR30052#c5
where 'runtest' was passing bogus target name when ran without
parameters:
$ ./result/bin/runtest
...
Target is .runtest-wrapped
Host is x86_64-pc-linux-gnu
Note that runtest switches to non-native mode and uses wrapper name as a
target name. Mechanics of it is a bit involved: 'runtest' itself detects
targets passing via ${0} parameter:
# somewhere in runtest:
mypath=${0-.}
...
if [ "$target" != runtest ] ; then
target="--target ${target}"
else
target=""
fi
which would be fine if we ran 'runtest'.
In `nixpkgs` `runtest` is a shell wrapper:
$ cat /<<NIX>>/dejagnu-1.6.3/bin/runtest
#! /<<NIX>>/bash-5.2-p15/bin/bash -e
...
exec -a "$0" "/<<NIX>>/dejagnu-1.6.3/bin/.runtest-wrapped" "$@"
You would expect that `.runtest-wrapped` would get `$0` as an `argv[0]`
here, but no. If both are `bash` scripts `bash` peeks original
`argv[0]` and breaks `runtest`:
https://lists.gnu.org/archive/html/bug-bash/2023-01/msg00082.html
The workaround here is to drop the wrapper and place `expect` symlink
into a place where `dejagnu` and `runtest` expect it to be without a
wrapper creation.
Trivial conflict in release notes, except that the xml/docbook parts
are horrible for (semi-)automatic conflict resolution.
Fortunately that's generated anyway.
