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:
|
ofborg
bot
added
10.rebuild-darwin-stdenv
ofborg
bot
added
10.rebuild-darwin: 501+
|
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/[email protected]/t/
trofi
force-pushed
the
binutils-update
branch
from
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. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
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 |
trofi
force-pushed
the
binutils-update
branch
from
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.outIt 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
trofi
force-pushed
the
binutils-update
branch
from
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 |
4 participants
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
libbfdandlibopcodesattributes to build inputs.libbfdandlibopcodesattributes now just referencebinutils-unwrapped.{dev,lib}pair of attributes without patchingbinutilsbuild system.We don't patch build system anymore and use multiple outputs out of existing
binutilsbuild. That makes the result more maintainable: no need to handle ever growing list of dependencied oflibbfd. This time new addition waslibsframe.To accomodate
out/liboutput split I had to removelib->binbackreference by removing legacy lookup path for plugins.I also did not enable
zstdjust yet asnixpkgsversion ofzstdpackage pulls incmakeinto bootstrap sequence.Changes: https://lists.gnu.org/archive/html/info-gnu/2023-01/msg00003.html
Description of changes
Things done
sandbox = trueset 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.shto update generated release notes