Question about Lavapipe and LLVM linking on Linux
Hi, I'm using Lavapipe 23.1.2 with a Vulkan rendering application in a Linux VM (Oracle 8, no gpu). Built in the same VM, with LLVM 15.0.7 (at the time) and statically linked against LLVM when building Lava (my thought was to eliminate dependencies for target machines as much as possible).
It was working great until some system updates happened (that seemed to have updated LLVM to 16.0.6, and then the application started crashing during its initialization/startup phase. The stack trace is as follows:
` Loguru caught a signal: SIGSEGV Stack trace: 39 0x7fb8cec93e73 clone + 67 38 0x7fb8d02161da /lib64/libpthread.so.0(+0x81da) [0x7fb8d02161da] 37 0x7fb7fd5c1f37 /home/user/app/libvulkan_lvp.so(+0x722f37) [0x7fb7fd5c1f37] 36 0x7fb7fd5d1f64 /home/user/app/libvulkan_lvp.so(+0x732f64) [0x7fb7fd5d1f64] 35 0x7fb7fd5d1bf9 /home/user/app/libvulkan_lvp.so(+0x732bf9) [0x7fb7fd5d1bf9] 34 0x7fb7fd778e06 /home/user/app/libvulkan_lvp.so(+0x8d9e06) [0x7fb7fd778e06] 33 0x7fb7fd78de3d /home/user/app/libvulkan_lvp.so(+0x8eee3d) [0x7fb7fd78de3d] 32 0x7fb7fd78c062 /home/user/app/libvulkan_lvp.so(+0x8ed062) [0x7fb7fd78c062] 31 0x7fb7fd888d27 /home/user/app/libvulkan_lvp.so(+0x9e9d27) [0x7fb7fd888d27] 30 0x7fb7fe772ea7 /home/user/app/libvulkan_lvp.so(+0x18d3ea7) [0x7fb7fe772ea7] 29 0x7fb7fe771908 /home/user/app/libvulkan_lvp.so(+0x18d2908) [0x7fb7fe771908] 28 0x7fb7fe76f4cd /home/user/app/libvulkan_lvp.so(+0x18d04cd) [0x7fb7fe76f4cd] 27 0x7fb7fe76eccb /home/user/app/libvulkan_lvp.so(+0x18cfccb) [0x7fb7fe76eccb] 26 0x7fb7fe76e07a /home/user/app/libvulkan_lvp.so(+0x18cf07a) [0x7fb7fe76e07a] 25 0x7fb7fd82ea58 /home/user/app/libvulkan_lvp.so(+0x98fa58) [0x7fb7fd82ea58] 24 0x7fb7fd86f850 /home/user/app/libvulkan_lvp.so(+0x9d0850) [0x7fb7fd86f850] 23 0x7fb7fd8809b7 /home/user/app/libvulkan_lvp.so(+0x9e19b7) [0x7fb7fd8809b7] 22 0x7fb7fd7b9361 /home/user/app/libvulkan_lvp.so(+0x91a361) [0x7fb7fd7b9361] 21 0x7fb7fdabf907 LLVMGetPointerToGlobal + 55 20 0x7fb7fdacec78 llvm::MCJIT::finalizeObject() + 408 19 0x7fb7fdacfb95 llvm::MCJIT::generateCodeForModule(llvm::Module*) + 1301 18 0x7fb7fdacf486 llvm::MCJIT::emitObject(llvm::Module*) + 374 17 0x7fb7fd9fa650 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 880 16 0x7fb7fd9f9d7b llvm::FPPassManager::runOnModule(llvm::Module&) + 59 15 0x7fb7fd9f9b44 llvm::FPPassManager::runOnFunction(llvm::Function&) + 756 14 0x7fb7feca2125 /home/user/app/libvulkan_lvp.so(+0x1e03125) [0x7fb7feca2125] 13 0x7fb7fe353324 /home/user/app/libvulkan_lvp.so(+0x14b4324) [0x7fb7fe353324] 12 0x7fb7ff64d05c /home/user/app/libvulkan_lvp.so(+0x27ae05c) [0x7fb7ff64d05c] 11 0x7fb7ff64ac2e llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 5374 10 0x7fb7ff648d87 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, true>, llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, true>, bool&) + 151 9 0x7fb7ff5f5b58 llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 72 8 0x7fb7ff5ed846 llvm::SelectionDAGBuilder::visitBinary(llvm::User const&, unsigned int) + 262 7 0x7fb7ff5d3252 llvm::SelectionDAGBuilder::getValue(llvm::Value const*) + 114 6 0x7fb7ff5cd49f llvm::SelectionDAGBuilder::getValueImpl(llvm::Value const*) + 239 5 0x7fb7ff62ecc5 llvm::SelectionDAG::getConstant(llvm::ConstantInt const&, llvm::SDLoc const&, llvm::EVT, bool, bool) + 389
4 0x7fb7ff5f95a5 llvm::SelectionDAG::FindNodeOrInsertPos(llvm::FoldingSetNodeID const&, llvm::SDLoc const&, void*&) + 53
3 0x7fb7fdf54d2c llvm::FoldingSetBase::FindNodeOrInsertPos(llvm::FoldingSetNodeID const&, void*&, llvm::FoldingSetBase::FoldingSetInfo const&) + 172
2 0x7fb8978aa6f8 /lib64/libLLVM-16.so(+0x16016f8) [0x7fb8978aa6f8]
1 0x7fb8978aa24f /lib64/libLLVM-16.so(+0x160124f) [0x7fb8978aa24f]
0 0x7fb8973dc894 llvm::MachinePointerInfo::getAddrSpace() const + 4 2023-12-05 13:09:45.082 (58.096s) [ F708E700] :0 FATL| Signal: SIGSEGV `
which shows that the new LLVM binaries are getting picked, and I can't figure out why/by whom.
I've noticed now that my OS is reporting "llvmpipe (LLVM 16.0.6, 256 bits)" as graphics in its "About" window. Also worth mentioning is that I can run vulkaninfo & vkcube with the existing Lavapipe binary and they seem to be working ok (no new LLVM binaries interference there?).
I tried rebuilding Lavapipe with LLVM 16 (dynamically linked this time) and the app started working again in my VM without any problems (expected). However now libLLVM-16.so is listed as a Lavapipe dependency (expected too) so I can't distribute the specific Lavapipe binary, since there could be other target machines for my app that may have not updated to LLVM 16 yet. So, my question is, what would be the proper way/best practice regarding linking with LLVM and distributing Lavapipe? I was hoping that dynamic linking without requiring a specific version could be possible but as I see know this is probably not the case (I wish I'm wrong here). Thanks in advance for any help!