-
Notifications
You must be signed in to change notification settings - Fork 11.6k
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
When suffixed with a version, llvm-strip is no longer recognized as llvm-strip #44616
Comments
assigned to @MaskRay |
I've bumped the importance of this. Almost certainly this could silently break behaviour for one or more people out there, since it changes the default behaviour of the tool to work like llvm-objcopy. https://reviews.llvm.org/D76562 addresses this. |
Should it be updated to block 44555 as well? |
Makes sense. I've done so, although it might be too late to add another blocker to the LLVM 10 release (we've already had 5 RCs!). |
Yes, given that this has come up so late in the process, I think it will have to wait for 10.0.1. |
This has been fixed with f2f96eb, please cherry-pick it for 10.0.1. |
Re-opening to track this for 10.0.1. |
Cherry-picked "[llvm-objcopy] Improve tool selection logic to recognize llvm-strip-$major as strip" |
Merged: 50d7e5d |
mentioned in issue #44654 |
Extended Description
Debian's apt.llvm.org symlinks all of the LLVM binaries from /usr/lib/llvm-/bin to /usr/bin/<tool_name>- (e.g. /usr/lib/llvm-11/bin/clang -> /usr/bin/clang-11) so that multiple versions of clang can be installed and used at one time without stepping over each other.
After commit c54959c ("Introduce llvm-install-name-tool"), llvm-strip fails to work in this configuration (as initially reported at ClangBuiltLinux/linux#940):
llvm-strip-11: error: unknown argument '-o'
This is because 'strip' is required to be the ending to the binary after this change, whereas before the binary merely needed to contain 'strip'. I am not familiar enough with LLVM data structures to try and fix this myself, hence this report (maybe moving back to using sys::path::stem(...).contains(...)?).
Should you need to reproduce:
The text was updated successfully, but these errors were encountered: