-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[linux] remove absolute rpath of /usr/lib/swift/linux added to many shared libraries #34303
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
Conversation
…hared libraries This was presumably added as a backup, in case the libraries in a toolchain couldn't be found, but will not work well, so take it out.
@gottesmm, this backports the rpath pull you merged today to the 5.3 branch. |
@swift-ci test |
Windows CI failure is unrelated. |
@drexin, there was no merge window announced for 5.3.1, doesn't look like there will be one for 5.3.2 either: could you get this pull and the approved swiftlang/swift-corelibs-xctest#308 into the 5.3 branch, as they're completely safe rpath changes for linux? |
@buttaface I'm sorry, I can only merge during the merge windows. |
Alright, thanks for letting me know. |
@tomerd, I'd like to finally get this in for |
@drexin, would you run the CI again? We should be able to get this in now. |
@swift-ci test |
cc @airspeedswift to approve taking into 5.3.3 |
@buttaface @airspeedswift had some questions on urgency of this, i.e can it wait for the 5.4 release? |
On the one hand, yes, it has been this way on linux since almost the beginning, so it could be delayed just a couple months longer. On the other hand, it represents almost no risk of breakage and closes up a small security hole- the attacker would have to remove one of these affected Swift libraries like In the end, I'd be fine with waiting if the reviewers come to a different conclusion: just close the pull if you'd rather wait, as it's already in the 5.4 branch. |
thanks @buttaface, we should probably just wait for 5.4 |
No problem. |
This RPATH was presumably added as a backup, in case the libraries in a toolchain couldn't be found, but will not work well, so take it out.
This pull is a cherry-pick of #34023 to the 5.3 branch.
Since the stdlib and these other Swift shared libraries all have
$ORIGIN
set, the toolchain should be self-contained and never have to go to/usr/lib
. In the rare occasion of a broken toolchain, eglibswiftCore.so
is missing, the other libraries might find one in the system that works. That is such a rare scenario, that is as likely to break if a different Swift version is installed in the system, that it's better not to have this.At least partially resolves SR-5755, fully if he's not saying we should add
CMAKE_INSTALL_PREFIX
to the RPATH instead, which I don't think should be added by default either.Low
I'm currently building SPM with the official Oct. 22 trunk snapshot build that had this pull merged and everything works fine.
I discussed these rpath issues in detail across the entire toolchain with @gottesmm and @compnerd.
@drexin, will a merge window for the 5.3.1 release be announced on the forums? I'd like to get this and swiftlang/swift-corelibs-xctest#308 in before the next patch release.