Julia: Add a build option to rename all LLVM symbols

[Keno]

A lot of libraries embed some version of LLVM nowadays (e.g. NVIDIA SDKs), which causes a problem when julia uses LLVM as a shared library. It would be great to have a Makefile option that prefixes all LLVM symbols with jl_ or some such.

[vtjnash]

when we link to llvm as a static library, i think we hide all of the symbols (partly because of this issue). when we link dynamically, it is often because we are linking to the system llvm (which we have no control over).

tl;dr i'm not sure this is going to work

[Keno]

There is plenty of reasons to use LLVM dynamically other than it being the system LLVM, we even have a Makefile option for it. In particular, it is used for Cxx.jl, so there's a number of people who run julia in this configuration.

[vtjnash]

Can we use dlopen(RTLD_LOCAL) and get the same effect, without the complications from doing renaming?

[tkelman]

codegen isn't dlopen'ing shared llvm, it's using normal linking

[yuyichao]

Would be nice if llvm has a namespace compile time option (like Qt).

[vchuravy]

We recently gotten a multitude of reports about this https://github.com/JuliaGPU/OpenCL.jl/issues/125#issuecomment-268078204 and https://discourse.julialang.org/t/llvm-problem-with-running-glfw-jl/1110 so it would be nice if we could work around this in Julia.

[stevengj]

I'm getting reports of this happening with PyPlot, too; apparently some Matplotlib backends link LLVM.

[ihnorton]

LLVM upstream has added --default-symver for this reason: https://reviews.llvm.org/D30997

[ihnorton]

If anyone is dealing with this right now, for the short term (note: on Linux): try dlopening the other LLVM-using library with Libdl. RTLD_DEEPBIND. Make sure that option is passed as the very first dlopen of a given library path -- the first load options dominate.

[dehann]

Hi All, I'm trying to install Clang.jl and ended up here too. Hope this adds value, and figured Clang.jl has a large impact on the Julia ecosystem. (Note this happens both w/ or wo/ Cxx.jl installed):

julia> Pkg.add("Clang")
...
LoadError: No useable llvm-config found
while loading /home/dehann/.julia/v0.6/Clang/deps/build.jl, in expression starting on line 64
...

Adding a system install sudo apt-get install llvm changes the behavior to:

INFO: Building Clang
INFO: Called Clang.jl:find_llvm
g++ wrapclang.cpp -fPIC -c -o wrapclang.cpp.o -I/usr/lib/llvm-3.4/include -g -I/usr/lib/llvm-3.4/include  -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -g -O2 -fomit-frame-pointer -fvisibility-inlines-hidden -fno-exceptions -fPIC -Woverloaded-virtual -Wcast-qual -Wall -Wno-strict-aliasing -fno-omit-frame-pointer -fPIC 
wrapclang.cpp:7:27: fatal error: clang-c/Index.h: No such file or directory
 #include "clang-c/Index.h"
                           ^
compilation terminated.
make: *** [wrapclang.cpp.o] Error 1
=======================================================================================[ ERROR: Clang ]========================================================================================

LoadError: clang headers could not be found and BUILD_LLVM_CLANG=1 not specified in Make.user
Try setting BUILD_LLVM_CLANG=1 in Make.user in /home/dehann/software/julia-0d7248e2ff/bin and try again.
while loading /home/dehann/.julia/v0.6/Clang/deps/build.jl, in expression starting on line 90

Setup is Ubuntu 16.04 or 14.04, and binary install of both Julia 0.6.0 and 0.6.1.

Thanks for the great work!

EDIT: ihnorton/Clang.jl#165

[GeraldKaeferle]

@dehann: try sudo apt-get install llvm-dev clang-dev. I t worked for me in Fedora with sudo dnf install llvm-dev clang-dev.

[stevengj]

I've gotten a couple of reports of segfaults when loading Python libraries for the same reason … a lot of things seem to be pulling in LLVM these days.

Any chance we can compile LLVM with --default-symver or similar sometime soon?

[dehann]

@GeraldKaeferle : thanks, sorry for slow reply -- on Ubuntu 16.04 the packages were llvm-dev and libclang-dev. With Julia 1.0, I was then able to add Clang and the tests pass. Thanks.

[stevengj]

@banex19, is this fixed by https://github.com/JuliaLang/julia/blob/master/deps/patches/llvm7-symver-jlprefix.patch (#31508) since that uses JL_LLVM_<major>_<minor> (instead of LLVM_<major>_<minor>) for symbol versioning?

Edit: Looks like the patch goes back earlier — was this fixed by #25597 (@vchuravy)?

[Orbots]

I've run into an issue recently where symver doesn't appear to help. #32616 I don't really understand DSO symbol resolution complications, they are counter-intuitive for someone used to the sanity of lexical scoping.

The conflicting lib did a reasonable thing and appear to have effectively done a find and replace for namespace llvm with their own custom namespace. This hides most of llvm's symbols from other llvm users. But not all of them.

} // end namespace llvm

extern "C" void LLVMInitializeX86Target() {

If you were to prefix anything in LLVM with jl_ I'd propose that some of these un-namespaced extern "C" procedures should be considered.

[ihnorton]

It looks like LLVM now does symbol versioning by default with a linker script:
https://github.com/llvm-mirror/llvm/blob/9070b54da16dfbd2f93be617aa42c06093678adb/tools/llvm-shlib/CMakeLists.txt#L55-L57

but that may not be sufficient, as it seems a number of projects are still encountering this issue (in both the Julia and Python ecosystems). I wonder if projects need to override that linker script and make the SOVERSION something like e.g. llvm_major.llvm_minor.julia, [v].[v].numba, etc. so that symbols are unique even when the version numbers are the same.

edit: nvm, that's what #31508 did, prefixing with JL_...

[vchuravy]

Yeah some of the remaining issues are caused by the usage of weaksymbols iirc in libclang, and maybe dlsym

[tkf]

What is the timeline to switch to use LLVM 7 by default, especially in the binary distributions?

Edit: never mind. I misunderstood that prefixing needs LLVM 7. Just saw https://github.com/JuliaLang/julia/issues/12644#issuecomment-484959352

[vchuravy]

As soon as someone manages to debug the windows failure we see on the LLVM
8.0.1 branch. https://github.com/JuliaLang/julia/pull/32712

On Wed, Aug 7, 2019, 01:11 Takafumi Arakaki [e-mail]
wrote:

What is the timeline to switch to use LLVM 7 by default, especially in the
binary distributions?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/12644?email_source=notifications&email_token=AABDO2V7ZJCFFYYX3DIG4CTQDIALZA5CNFSM4BNRPNK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3WW6QI#issuecomment-518876993,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDO2XAUTOIFXWFAKKBOTDQDIALZANCNFSM4BNRPNKQ
.

[Orbots]

For a really solid solution, renaming LLVM symbols appears to be most fool-proof solution.
If an unversioned set of llvm symbols has been loaded into a program before julia, then symbol versioning will not fix the problems.

If you have full control over what shared libraries are loaded or the order they are loaded in you can work around this. If you can't, then you have a fragile situation.