Arch Linux

Our libLLVM.so has contained versioned symbols starting with LLVM 5, through the linker script added in [1].

I asked for clarification on the LLVM_DYLIB_SYMBOL_VERSIONING option, since I'm not sure how it relates to the linker script. [2]

[1] https://github.com/llvm-mirror/llvm/commit/cd789d8cfe
[2] https://reviews.llvm.org/D30997#1095542

Just did a quick test and created an empty terminal application in KDevelop, after having installed mesa-git [1].

Looking at the output of lsof, it has loaded:

- /usr/lib/libclang.so.6
- /usr/lib/libLLVM-6.0.so
- /usr/lib/libLLVM-7svn.so

So it seems to work fine for me.

Perhaps there is an issue with your custom LLVM 7 installation and/or some other weird interaction with Mesa or KDevelop.

[1] https://wiki.archlinux.org/index.php/Unofficial_user_repositories#mesa-git

Huh, could you always install both llvm-libs packages without conflicts? That's interesting.

Just to make sure: The kdevelop clang plugin crashes silently, you only see messages "libclang: crash detected during parsing: " etc. when starting kdevelop from a terminal.

I've seen the script but did not look close enough to see that it was not the same feature as the one enabled with LLVM_DYLIB_SYMBOL_VERSIONING which is disabled by default. So llvm is already supposed to version its libraries by default?
Apologies for the confusion then.

But I still don't understand why it crashes for me (when statically linking llvm into mesa, it doesn't crash).
My llvm build is this: https://gist.github.com/ChristophHaag/9119c43aef94d8d43bb3087ad04991b1
I first had it without -DLLVM_DYLIB_SYMBOL_VERSIONING=ON but with it on it doesn't make a difference.

I have /usr/lib/llvm-mesa/lib/ in my linker search path and one possible problem I see is that it creates /usr/lib/llvm-mesa/lib/libLLVM.so which may clash with /usr/lib/libLLVM.so but I thought symbol versioning would take care of that.

Anyway, I will experiment a bit more, starting with -DLLVM_APPEND_VC_REV=ON. Maybe I can close this issue as invalid soon.

So maybe this is not a symbol versioning issue. With LD_DEBUG=libs everything looks in order and readelf -Ws shows the functions are properly versioned @@LLVM_6.0 vs @@LLVM_7. Maybe there is something else going on...

For reference: This is the crash that does not happen when I link llvm7 statically to mesa or use a mesa linked to llvm6: https://gist.github.com/ChristophHaag/0c42c799f26b2c7557c7ae8237d9b194

It could be caused by the lack of versioned symbols in all the little libclang*.so.6 libraries (possibly my fault for building with BUILD_SHARED_LIBS=ON).

I'll take a closer look when I can and see if this can be addressed.

I doubt it because it's a minimal llvm build completely without clang, clover isn't really worth it. But thanks for looking, currently I have no idea what the problem is.

ls -1 /usr/lib/llvm-mesa/lib/
BugpointPasses.so
cmake
libLLVM-7.0.0svn.so
libLLVM-7svn.so
libLLVMAggressiveInstCombine.a
libLLVMAMDGPUAsmParser.a
libLLVMAMDGPUAsmPrinter.a
libLLVMAMDGPUCodeGen.a
libLLVMAMDGPUDesc.a
libLLVMAMDGPUDisassembler.a
libLLVMAMDGPUInfo.a
libLLVMAMDGPUUtils.a
libLLVMAnalysis.a
libLLVMAsmParser.a
libLLVMAsmPrinter.a
libLLVMBinaryFormat.a
libLLVMBitReader.a
libLLVMBitWriter.a
libLLVMCodeGen.a
libLLVMCore.a
libLLVMCoroutines.a
libLLVMCoverage.a
libLLVMDebugInfoCodeView.a
libLLVMDebugInfoDWARF.a
libLLVMDebugInfoMSF.a
libLLVMDebugInfoPDB.a
libLLVMDemangle.a
libLLVMDlltoolDriver.a
libLLVMExecutionEngine.a
libLLVMFuzzMutate.a
libLLVMGlobalISel.a
libLLVMInstCombine.a
libLLVMInstrumentation.a
libLLVMInterpreter.a
libLLVMipo.a
libLLVMIRReader.a
libLLVMLibDriver.a
libLLVMLineEditor.a
libLLVMLinker.a
libLLVMLTO.a
libLLVMMC.a
libLLVMMCDisassembler.a
libLLVMMCJIT.a
libLLVMMCParser.a
libLLVMMIRParser.a
libLLVMObjCARCOpts.a
libLLVMObject.a
libLLVMObjectYAML.a
libLLVMOption.a
libLLVMOrcJIT.a
libLLVMPasses.a
libLLVMProfileData.a
libLLVMRuntimeDyld.a
libLLVMScalarOpts.a
libLLVMSelectionDAG.a
libLLVM.so
libLLVMSupport.a
libLLVMSymbolize.a
libLLVMTableGen.a
libLLVMTarget.a
libLLVMTransformUtils.a
libLLVMVectorize.a
libLLVMWindowsManifest.a
libLLVMXRay.a
libLTO.so
libLTO.so.7
libLTO.so.7svn
LLVMgold.so
LLVMHello.so

libclangBasic.so.6 contains some unversioned symbols that reference LLVM types and that might be conflicting with libLLVM-7svn.so.

I'm not really sure what's going on either. :-)