linux/bootstrap-tools: move libstdc++ out of default library search path #209054
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change allows building new gcc during bootstrap without fear of
pulling in outdated libstdc++.so after g++ switched from bootstrapTools
to freshly built g++.
Noticed when tried to add early bootstrap stage to rebuild `gcc` before
`glibc` is fully untangled from `bootstrapTools` as a failure to built
`binutils`:
ld: dwp.o: in function `__gnu_cxx::new_allocator<gold::Dwp_output_file::Contribution>::allocate(unsigned long, void const*)':
/nix/store/...-gcc-11.3.0/include/c++/11.3.0/ext/new_allocator.h:116: undefined reference to `std::__throw_bad_array_new_length()'
The change survives existing bootstrap and unblockes early `gcc` bootstrap.
ofborg
bot
added
10.rebuild-linux-stdenv
ghost
approved these changes
Jan 9, 2023
| @@ -17,6 +17,15 @@ else | |||
| LD_BINARY=$out/lib/ld-*so.? | |||
| fi | |||
|
|
|||
| # path to version-specific libraries, like libstdc++.so | |||
| LIBSTDCXX_SO_DIR=$(echo $out/lib/gcc/*/*) | |||
There was a problem hiding this comment.
I checked that for all 16 of our existing bootstrap-files tarballs there is only one subdirectory under lib/gcc, and only one subdirectory beneath that (unpack-bootstrap-tools.sh is a huge pain because every time we touch it we have to rebuild the whole universe).
ghost
mentioned this pull request
|
This regressed tests for bootstrap tarball building: I think it's a pure test issue. Test does not use any wrappers and assumes certain directory layout. Looking. |
trofi
added a commit
to trofi/nixpkgs
that referenced
this pull request
Jan 14, 2023
After NixOS#209054 we started moving libstdc++.so out of default glibc's paths. This exposed bootstrap tools build failure as: $ nix build --no-link -f ./pkgs/stdenv/linux/make-bootstrap-tools.nix ... > .../bin/bar: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Note that bootstrap itself did not break. The change only expands handcrafted `-rpath` entries.
13 tasks
|
Proposed the fix as #210752 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change allows building new gcc during bootstrap without fear of pulling in outdated libstdc++.so after g++ switched from bootstrapTools to freshly built g++.
Noticed when tried to add early bootstrap stage to rebuild
gccbeforeglibcis fully untangled frombootstrapToolsas a failure to builtbinutils:The change survives existing bootstrap and unblockes early
gccbootstrap.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