Consistently use RUNPATH in our libraries
#46464
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When loading dependencies on Linux, we can either use `RPATH` or `RUNPATH` as a list of relative paths to search for libraries. The difference, for our purposes, mainly lies within how this interacts with `LD_LIBRARY_PATH`: `RPATH` is searched first, then `LD_LIBRARY_PATH`, then `RUNPATH`. So by using `RUNPATH` here, we are explicitly allowing ourselves to be overridden by `LD_LIBRARY_PATH`. This is fine, as long as we are consistent across our entire library line, however in the `v1.8.0` release, there was an inconsistency, reported in [0]. The inconsistency occured because of the following confluence of factors: - Ancient `ld` builds (such as the one used in our build environment) do not default to using `RUNPATH`, but instead use `RPATH`. - `patchelf`, when it rewrites the RPATH, will default to using `RUNPATH` instead. - We were only using `patchelf` on `libjulia-internal`, not on `libjulia-codegen`, which was newly added in `v1.8`. These three factors together caused us to ship a binary with `RUNPATH` in `libjulia-internal`, but `RPATH` in `libjulia-codegen`, which caused loading to fail in [0] due to first `libjulia-internal` being loaded, (which brought in the external `libstdc++`), then `libjulia-codegen` failed to load (because it found an incompatible `libstdc++`), causing the mysterious compiler error. This PR fixes this twofold; first, when building the libraries in the first place, we pass `--enable-new-dtags` to the linker to encourage it to use `runpath` when possible. This removes the possibility for a missing `patchelf` invocation to break things in this way. Second, we apply `patchelf` properly to `libjulia-codegen` as well. [0] #46409
Keno
approved these changes
Aug 23, 2022
giordano
added
building
giordano
reviewed
Aug 23, 2022
Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com>
35 tasks
vtjnash
added a commit
to JuliaPackaging/Yggdrasil
that referenced
this pull request
Oct 25, 2022
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When loading dependencies on Linux, we can either use
RPATHorRUNPATHas a list of relative paths to search for libraries. Thedifference, for our purposes, mainly lies within how this interacts with
LD_LIBRARY_PATH:RPATHis searched first, thenLD_LIBRARY_PATH,then
RUNPATH. So by usingRUNPATHhere, we are explicitly allowingourselves to be overridden by
LD_LIBRARY_PATH. This is fine, as longas we are consistent across our entire library line, however in the
v1.8.0release, there was an inconsistency, reported in [0].The inconsistency occured because of the following confluence of factors:
ldbuilds (such as the one used in our build environment)do not default to using
RUNPATH, but instead useRPATH.patchelf, when it rewrites the RPATH, will default to usingRUNPATHinstead.patchelfonlibjulia-internal, not onlibjulia-codegen, which was newly added inv1.8.These three factors together caused us to ship a binary with
RUNPATHin
libjulia-internal, butRPATHinlibjulia-codegen, which causedloading to fail in [0] due to first
libjulia-internalbeing loaded,(which brought in the external
libstdc++), thenlibjulia-codegenfailed to load (because it found an incompatible
libstdc++), causingthe mysterious compiler error.
This PR fixes this twofold; first, when building the libraries in the
first place, we pass
--enable-new-dtagsto the linker to encourage itto use
runpathwhen possible. This removes the possibility for amissing
patchelfinvocation to break things in this way. Second, weapply
patchelfproperly tolibjulia-codegenas well.[0] #46409