Don't add rpath to swift with statically linking #10381
Conversation
|
@swift-ci please test |
|
Build failed |
| @@ -1283,10 +1284,10 @@ toolchains::Darwin::constructInvocation(const LinkJobAction &job, | |||
| Arguments.push_back(context.Args.MakeArgString(LibProfile)); | |||
| } | |||
|
|
|||
| // FIXME: We probably shouldn't be adding an rpath here unless we know ahead | |||
| // of time the standard library won't be copied. | |||
There was a problem hiding this comment.
Please preserve this FIXME in the new code as well—it's referencing the rest of SR-1967.
There was a problem hiding this comment.
Done, also moved this up into the else above
This updates the rpath linking logic to only add the rpath that points to the swift dylibs in the case that the libraries are not statically linked into the binary.
|
Yep I'll look at adding that test! |
|
(sorry about the tests, the first push here was bogus) |
|
@swift-ci please test |
|
I've just pushed a test for this. I would love some feedback on how I'm using // SWIFT_STATIC-DAG-NOT: -rpathInstead I'm using the |
This test validates the arguments passed to the linker when statically linking the swift standard library. Currently in order to ensure that no -rpath is passed, we're using FileCheck's -implicit-check-not flag, and strictly validating the order of the arguments. The order doesn't really matter here but is required for that flag to validate that no -rpath is passed.
|
@swift-ci please test |
|
Build failed |
|
Looks like these failures are because I force pushed, it's still building the new sha. |
|
@swift-ci please test |
|
(it seems to still be running) |
|
@swift-ci please smoke test OS X Platform |
|
Thanks! |
This updates the rpath linking logic to only add the rpath that points
to the swift dylibs in the case that the libraries are not statically
linked into the binary.
This fix is marginally relevant to https://bugs.swift.org/browse/SR-1967, but does not solve the core problem here.