Eliminate @loader_path/julia element of DL_LOAD_PATH
#42930
Conversation
Analogous to 236523f, we don't need to search in `@loader_path/julia` anymore, as `libjulia-internal` is now consistently within the same directory as our other dependencies.
Codecov Report
@@ Coverage Diff @@
## master #42930 +/- ##
=======================================
Coverage 89.20% 89.20%
=======================================
Files 343 343
Lines 79912 79912
=======================================
Hits 71285 71285
Misses 8627 8627 Continue to review full report at Codecov.
|
|
This seems to fix #42882 for me. |
|
Great; does it fix #42875 as well? You can download https://s3.amazonaws.com/julialangnightlies/assert_pretesting/mac/x64/1.8/julia-30861bd763-mac64.tar.gz to test. |
|
Hard to tell because Monterey infuriatingly gets in the way of using software. It just keeps telling me that "libopenlibm.3.0.dylib is damaged and can't be opened. You should move it to the Trash" and not letting me actually start Julia. |
|
Interesting; sounds like a codesigning issue. Ian verified that it worked on his Monterey machine, so I'm going to merge this. Alex, at your leisure, feel free to DM me on slack, and I'll try to figure out your codesigning problems. |
…2930) Analogous to JuliaLang@236523f, we don't need to search in `@loader_path/julia` anymore, as `libjulia-internal` is now consistently within the same directory as our other dependencies.
…2930) Analogous to JuliaLang@236523f, we don't need to search in `@loader_path/julia` anymore, as `libjulia-internal` is now consistently within the same directory as our other dependencies.
Analogous to 236523f, we don't need to search in
@loader_path/juliaanymore, aslibjulia-internalis now consistently within the same directory as our other dependencies.