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
Fix rpath-related Linux "test_shlibload" failure. [1.1.0] #7631
Conversation
When libssl and libcrypto are compiled on Linux with "-rpath", but not "--enable-new-dtags", the RPATH takes precedence over LD_LIBRARY_PATH, and we end up running with the wrong libraries. This is resolved by using full (or at least relative, rather than just the filename to be found on LD_LIBRARY_PATH) paths to the shared objects.
Thanks. Looks promising, will let you know how the tests went shortly... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good to go. Moving on to the 1.1.1 version next...
Appveyor disagrees with you... hold on |
We therefore must add defaults.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reconfirming.
When libssl and libcrypto are compiled on Linux with "-rpath", but not "--enable-new-dtags", the RPATH takes precedence over LD_LIBRARY_PATH, and we end up running with the wrong libraries. This is resolved by using full (or at least relative, rather than just the filename to be found on LD_LIBRARY_PATH) paths to the shared objects. Reviewed-by: Viktor Dukhovni <viktor@openssl.org> (Merged from #7631)
We therefore must add defaults. Reviewed-by: Viktor Dukhovni <viktor@openssl.org> (Merged from #7631)
When libssl and libcrypto are compiled on Linux with "-rpath", but
not "--enable-new-dtags", the RPATH takes precedence over
LD_LIBRARY_PATH, and we end up running with the wrong libraries.
This is resolved by using full (or at least relative, rather than
just the filename to be found on LD_LIBRARY_PATH) paths to the
shared objects.
This is a backport of #7626