Skip to content
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

Merged
merged 3 commits into from
Jan 29, 2023
Merged

binutils: 2.39 -> 2.40 #211126

merged 3 commits into from
Jan 29, 2023

Conversation

trofi
Copy link
Contributor

@trofi trofi commented Jan 16, 2023

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

Description of changes
Things done
  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 23.05 Release Notes (or backporting 22.11 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
    • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
  • Fits CONTRIBUTING.md.

@trofi
Copy link
Contributor Author

trofi commented Jan 16, 2023

Apart from binutils possibly able to fail kernel build (there are some DRAWF generation changes that might need a new pahole release) I also did a bit of nixpkgs-specific changes: -lbfd library is not visible by default until you include libbfd attribute. I don't expect too many build failures, but there might be some.

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:

  • build my full system
  • build all reverse dependencies that mention:
    • libbfd
    • libopcodes
    • binutils-unwrapped
    • binutils-unwrapped-all-targets
  • build a few cross-compilers: TODO list of tried ones
  • fix the fallout:
    • linux_latest fails due to pahole limitation (needs pahole update): Unsupported DW_TAG_unspecified_type(0x3b)
    • llvm_12: fails to find plugin-api.h in libbfd.dev

@trofi trofi marked this pull request as draft January 17, 2023 00:14
trofi added a commit to trofi/nixpkgs that referenced this pull request Jan 18, 2023
…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.
@trofi
Copy link
Contributor Author

trofi commented Jan 18, 2023

Fixed llvm12 by avoiding plugin use for wasi default targets.

…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/
@trofi
Copy link
Contributor Author

trofi commented Jan 18, 2023

Built my system and booted it successfully in qemu. I think it's good enough for review.

@trofi trofi marked this pull request as ready for review January 18, 2023 23:15
@SuperSandro2000
Copy link
Member

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.

Copy link
Contributor Author

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
Copy link

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.

Copy link
Contributor Author

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.

Comment on lines +107 to +115
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.

@vcunat
Copy link
Member

vcunat commented Jan 21, 2023

Hydra jobset for stabilization: https://hydra.nixos.org/jobset/nixpkgs/pr-211126-binutils-2.40

@github-actions github-actions bot added the 6.topic: stdenv Standard environment label Jan 24, 2023
@trofi
Copy link
Contributor Author

trofi commented Jan 24, 2023

Fixing minor snag on darwin where allowedRequisites had to be extended slightly to cover split binutils as:

--- 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.

@trofi
Copy link
Contributor Author

trofi commented Jan 27, 2023

Failures:

  • (aarch64-linux) libbfd and libopcodes (log):

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
Copy link
Contributor Author

trofi commented Jan 28, 2023

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

@trofi
Copy link
Contributor Author

trofi commented Jan 28, 2023

Skimmed through https://hydra.nixos.org/jobset/nixpkgs/pr-211126-binutils-2.40 and did not find any build failure related to binutils. I would say it is looking great!

@trofi trofi merged commit 0ba9da4 into NixOS:staging Jan 29, 2023
@trofi trofi deleted the binutils-update branch January 29, 2023 09:51
@martinetd
Copy link
Member

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)

@trofi
Copy link
Contributor Author

trofi commented Mar 13, 2023

ofborg should look at all the commits. The green arrow against e1ef521 has this detail on maintainers specified: https://gist.github.com/GrahamcOfBorg/03fefe23cc2d730a4ac58f66d28872ed

martinetd: pahole, pahole

I would expect you to be CCed. Worth asking ofborg maintainers?

@martinetd
Copy link
Member

Thanks, I've asked in NixOS/ofborg#636

@martinetd martinetd self-requested a review March 13, 2023 10:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants