llvmPackages.bintools-unwrapped: add missing symlinks#211161
llvmPackages.bintools-unwrapped: add missing symlinks#211161alyssais merged 2 commits intoNixOS:masterfrom
Conversation
We were missing symlinks for some programs e.g. strings, which caused e.g. pkgsLLVM.x264 to fail to build. Here, I have filled in all the symlinks that LLVM would create if built with the LLVM_INSTALL_BINUTILS_SYMLINKS option. Where an existing symlink's target has changed, it's to avoid a double indirection e.g. strip -> llvm-strip -> llvm-objcopy has because just strip -> llvm-objcopy. There's also the related problem that we are creating a as -> llvm-as symlink, which doesn't make sense, but I'll remove that in a subsequent commit so that if it somehow breaks something it's easy to revert just that change. Fixes: NixOS#210983
"llvm-as is an LLVM IR -> LLVM bitcode assembler not a system assembler"[1], and therefore should not be linked as "as". The "as" symlink was removed in 46e5ea5 ("llvm*: remove symlinks to llvm-diff, llvm-as and associated LLVM IR utilities."), but that was partially reverted by b331c72 ("llvm: setup some symlinks for compatibility with binutils"), which restored a bunch of symlinks that were incorrectly removed, but also incorrectly restored "as". This was pointed out[2] at the time but apparently never fixed. [1]: NixOS#93523 (comment) [2]: NixOS@b331c72#commitcomment-40981705
sternenseemann
left a comment
There was a problem hiding this comment.
What made you decide against LLVM_INSTALL_BINUTILS_SYMLINKS?
I presume the LLVM rebuild required? Though I think that may be better long-term if that's the only reason. (We do symlink other things manually even before this, though? IDK.) |
|
I decided to do it this way mostly because I noticed we were already doing it, and I didn't feel like there was a good reason to change. I didn't want to build with symlinks all the time, because I worried that could interfere with GNU stdenv builds, and I didn't want to add another |
See NixOS#194634 (comment) for details. PRs: - NixOS#211401 - NixOS#211161 - NixOS#206742 - NixOS#211687
See #194634 (comment) for details. PRs: - #211401 - #211161 - #206742 - #211687
|
Sorry, just getting back to this.
What did you mean by this? I can't find any e.g. recent issues surrounding this. |
See NixOS#194634 (comment) for details. PRs: - NixOS#211401 - NixOS#211161 - NixOS#206742 - NixOS#211687
|
@winterqt The relevant code is littered with comments like this one: nixpkgs/lib/systems/default.nix Lines 56 to 61 in b467aaa |
Description of changes
We were missing symlinks for some programs e.g. strings, which caused
e.g. pkgsLLVM.x264 to fail to build.
Here, I have filled in all the symlinks that LLVM would create if
built with the LLVM_INSTALL_BINUTILS_SYMLINKS option. Where an
existing symlink's target has changed, it's to avoid a double
indirection e.g. strip -> llvm-strip -> llvm-objcopy has because just
strip -> llvm-objcopy.
There's also the related problem that we are creating a as -> llvm-as
symlink, which doesn't make sense, but I've removed that in a
separate commit so that if it somehow breaks something it's easy to
revert just that change.
"llvm-as is an LLVM IR -> LLVM bitcode assembler not a system
assembler"1, and therefore should not be linked as "as".
The "as" symlink was removed in 46e5ea5 ("llvm*: remove symlinks
to llvm-diff, llvm-as and associated LLVM IR utilities."), but that
was partially reverted by b331c72 ("llvm: setup some symlinks for
compatibility with binutils"), which restored a bunch of symlinks that
were incorrectly removed, but also incorrectly restored "as". This
was pointed out2 at the time but apparently never fixed.
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