Move libstdc++ path into LOADER_*_DEP_LIBS
#48342
Conversation
staticfloat
added
backport 1.9
|
This should fix #47987 |
|
Fixes the build on Linux for Homebrew. Thanks! |
After adding `libstdc++` probing into the Julia loader [0], we originally made the assumption that the `libstdc++` that is shipped with `julia` would always be co-located with `libjulia.so` [1]. This is not the case when building with `USE_SYSTEM_CSL=1`, however, where we sequester system libraries in `usr/lib/julia`, even at build-time. The path to `libstdc++.so` has already been getting altered when moving from build-time to install time via `stringreplace` [2], but after further thought, I decided that it would be better to just use the pre-existing `LOADER_*_DEP_LIBS` mechanism to communicate to the loader what the correct relative path to `libstdc++.so` is. This also allows the single `stringreplace` to update all of our "special" library paths. [0] #46976 [1] https://github.com/JuliaLang/julia/pull/46976/files#diff-8c5c98f26f3f7aac8905a1074c5bec11a57e9b9c7c556791deac5a3b27cc096fR379 [2] https://github.com/JuliaLang/julia/blob/master/Makefile#L430
The `DEPS_LIBS` RPATH-substitute mechanism contains a list of paths to load, and some of these paths are "special", in that they require more involved loading than simply `load_library()`. These libraries are thereby denoted by a `@` prefixing them. Previously, we made note of these libraries, then loaded them at the end of the loading loop, but with the addition of `libstdc++` it is now important to have the order of the libraries (including special libraries) to be obeyed by the loading loop, so I have inlined special library handling into the loading loop. In the future, we may wish to denote special libraries more explicitly than simply relying on there being exactly three libraries, with the ordering being mapped to `libstdc++`, `libjulia-internal`, and `libjulia-codegen`.
staticfloat
force-pushed
the
sf/libstdcxx_probe_use_system_csl
branch
from
f7176c0 to
4e99860
Compare
|
I've now pushed a commit that causes the library loading (including special libraries) to obey the order as specified in
This ordering is important because As an aside, we now basically have a little switch statement in our library loading that does different things based on which "special library" we're processing; if we get much fancier than this (e.g. if we end up doing more probes for system libraries than just |
| @@ -1465,7 +1465,7 @@ JULIA_SYSIMG_release := $(build_private_libdir)/sys.$(SHLIB_EXT) | |||
| JULIA_SYSIMG := $(JULIA_SYSIMG_$(JULIA_BUILD_MODE)) | |||
|
|
|||
| define dep_lib_path | |||
| $$($(PYTHON) $(call python_cygpath,$(JULIAHOME)/contrib/relative_path.py) $(1) $(2)) | |||
| $(shell $(PYTHON) $(call python_cygpath,$(JULIAHOME)/contrib/relative_path.py) $(1) $(2)) | |||
There was a problem hiding this comment.
This slows things down a bit (adds ~60ms to every make invocation on my linux desktop) but I think it's worth it for the extra clarity.
DilumAluthge
removed
the
merge me
After adding
libstdc++probing into the Julia loader [0], we originally made the assumption that thelibstdc++that is shipped withjuliawould always be co-located withlibjulia.so[1]. This is not the case when building withUSE_SYSTEM_CSL=1, however, where we sequester system libraries inusr/lib/julia, even at build-time.The path to
libstdc++.sohas already been getting altered when moving from build-time to install time viastringreplace[2], but after further thought, I decided that it would be better to just use the pre-existingLOADER_*_DEP_LIBSmechanism to communicate to the loader what the correct relative path tolibstdc++.sois. This also allows the singlestringreplaceto update all of our "special" library paths.[0] #46976
[1] https://github.com/JuliaLang/julia/pull/46976/files#diff-8c5c98f26f3f7aac8905a1074c5bec11a57e9b9c7c556791deac5a3b27cc096fR379 [2] https://github.com/JuliaLang/julia/blob/master/Makefile#L430
Fix #47987.