-
-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
binutils: 2.39 -> 2.40 #211126
binutils: 2.39 -> 2.40 #211126
Conversation
Apart from I'm wondering if we should create a hydra jobset to see how much fallout we will have. Before doing that I'd still like to:
|
…in on wasi In NixOS#211126 I simplified `binutils` and `libbfd` derivations to follow upstream binutils build system closer. As a result of `./configure --target=wasm32-unknown-wasi` `binutils` does not install plugin headers by default. This causes `pkgsCross.wasi32.llvm_12` (used by `firefox`) to fail the build as: [ 81%] Building CXX object tools/gold/CMakeFiles/LLVMgold.dir/gold-plugin.cpp.o /build/llvm/tools/gold/gold-plugin.cpp:38:10: fatal error: plugin-api.h: No such file or directory 38 | #include <plugin-api.h> | ^~~~~~~~~~~~~~ The change accomodates this constraint to disable plugin support for `wasi` targets.
Fixed |
…in on wasi In NixOS#211126 I simplified `binutils` and `libbfd` derivations to follow upstream binutils build system closer. As a result of `./configure --target=wasm32-unknown-wasi` `binutils` does not install plugin headers by default. This causes `pkgsCross.wasi32.llvm_12` (used by `firefox`) to fail the build as: [ 81%] Building CXX object tools/gold/CMakeFiles/LLVMgold.dir/gold-plugin.cpp.o /build/llvm/tools/gold/gold-plugin.cpp:38:10: fatal error: plugin-api.h: No such file or directory 38 | #include <plugin-api.h> | ^~~~~~~~~~~~~~ The change accomodates this constraint to disable plugin support for `wasi` targets.
We need newer pahole to support `binutils-2.40` which started generating fresh DWARF tags that pahole-1.24 does not yet understand and fails as: $ nix log /nix/store/ckjr3sbsh13y1prigppk2y0jpf0p4icm-linux-6.1.6.drv ... BTF .btf.vmlinux.bin.o Unsupported DW_TAG_unspecified_type(0x3b) Encountered error while encoding BTF. Upstream thread to add the support for it: https://lore.kernel.org/all/YzwkazNc6wNCpQTN@kernel.org/t/
1aab85e
to
08748c9
Compare
Built my |
Way out of my compiler knowledge but this reminds me to share the code between llvm/gcc versions again. |
@@ -5,6 +5,7 @@ | |||
, cmake | |||
, python3 | |||
, libffi | |||
, enableGoldPlugin ? (!stdenv.isDarwin && !stdenv.targetPlatform.isWasi) |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expected the change to trigger firefox (and llvm targeting wasm) to rebuild:
] ++ optionals (enableGoldPlugin) [
"-DLLVM_BINUTILS_INCDIR=${libbfd.dev}/include"
It's not too much of a rebuld, but I'd still like to have it here if it's not too much of a complexity for the whole PR.
# Ideally we would like to always install 'lib' into a separate | ||
# target. Unfortunately cross-compiled binutils installs libraries | ||
# across both `$lib/lib/` and `$out/$target/lib` with a reference | ||
# from $out to $lib. Probably a binutils bug: all libraries should go |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree.
I fought with this for a few hours trying to fix up all the contorted paths that binutils' make install
creates and finally gave up.
# to $lib as binutils does not build target libraries. Let's make our | ||
# life slightly simpler by installing everything into $out for | ||
# cross-binutils. | ||
++ lib.optionals (targetPlatform == hostPlatform) [ "lib" ]; |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'd like to fix it upstream first as binutils
does not seem to install any target-specific libraries outside lib/
. The split between libbfd.so
and libsframe.so
locations does not look intentional. Once it's sorted we could bring both cases closer (either by using or not by using target prefixes consistently).
I can understand why FHS system wants to distinguish two binutils
installs for two different targets in a single prefix. Maybe it's worth fixing as well.
outputs = [ "out" "info" "man" "dev" ] | ||
# Ideally we would like to always install 'lib' into a separate | ||
# target. Unfortunately cross-compiled binutils installs libraries | ||
# across both `$lib/lib/` and `$out/$target/lib` with a reference | ||
# from $out to $lib. Probably a binutils bug: all libraries should go | ||
# to $lib as binutils does not build target libraries. Let's make our | ||
# life slightly simpler by installing everything into $out for | ||
# cross-binutils. | ||
++ lib.optionals (targetPlatform == hostPlatform) [ "lib" ]; |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Hydra jobset for stabilization: https://hydra.nixos.org/jobset/nixpkgs/pr-211126-binutils-2.40 |
08748c9
to
81eb44f
Compare
Fixing minor snag on --- a/pkgs/stdenv/darwin/default.nix
+++ b/pkgs/stdenv/darwin/default.nix
@@ -733,6 +733,7 @@ rec {
pcre.out
gettext
binutils.bintools
+ binutils.bintools.lib
darwin.binutils
darwin.binutils.bintools
curl.out It does not affect existing linux builds. |
Failures:
|
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
81eb44f
to
e1ef521
Compare
Fixed wrappers as: --- a/pkgs/development/tools/misc/binutils/libbfd.nix
+++ b/pkgs/development/tools/misc/binutils/libbfd.nix
@@ -8,6 +8,7 @@ stdenv.mkDerivation {
dontUnpack = true;
dontBuild = true;
+ dontInstall = true;
propagatedBuildInputs = [
binutils-unwrapped-all-targets.dev
binutils-unwrapped-all-targets.lib |
Skimmed through https://hydra.nixos.org/jobset/nixpkgs/pr-211126-binutils-2.40 and did not find any build failure related to |
BTW not complaning here, but does any of you know why ofborg didn't add me as reviewer on this PR that upgraded pahole? (I recall something about it looking only at PR title? I guess when doing some mass modification we wouldn't want it to notify everyone, but while I appreciate the work done I didn't like finding out pahole was on a random commit when someone upgraded it again because it failed build 6.3-rc1 and I had to find out what happened... Well in that case as well I wonder what maintainers are for if I'm only notified after someone pushes another upgrade and not when there's a problem, but I guess that second upgrade was straightforward enough to do directly) |
I would expect you to be CCed. Worth asking |
Thanks, I've asked in NixOS/ofborg#636 |
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
andlibopcodes
attributes to build inputs.libbfd
andlibopcodes
attributes now just referencebinutils-unwrapped.{dev,lib}
pair of attributes without patchingbinutils
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 oflibbfd
. This time new addition waslibsframe
.To accomodate
out
/lib
output split I had to removelib
->bin
backreference by removing legacy lookup path for plugins.I also did not enable
zstd
just yet asnixpkgs
version ofzstd
package pulls incmake
into bootstrap sequence.Changes: https://lists.gnu.org/archive/html/info-gnu/2023-01/msg00003.html
Description of changes
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes