https://bugzilla.suse.com/show_bug.cgi?id=1219405 https://bugzilla.suse.com/show_bug.cgi?id=1219405#c2 --- Comment #2 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Shung-Hsi Yu from comment #0)
Trying to install older clang will pull in the latest llvm package (libclang13 and libLLVM17):
While libclang13 from llvm17 is preferred, you should still be able to install llvm16-libclang13 as long as you have no need for libclang13 >= 17.
The problem is likely that c-index-test-16 is incorrectly linked to /lib64/libclang.so.13 that is created from the latest llvm package (llvm17 at the moment) [...]
I'm not sure if that's incorrect. The libclang API/ABI is supposed to be stable, and newer versions should be backwards-compatible, so we shouldn't need to increase the SO version. You should be able to replace libclang13 from llvm16 by libclang13 from llvm17 without issues unless you're making assumptions beyond guarantees provided by the interface. (An example of this would be bug 1210176, where the user made assumptions about the formatting of "identifiers" for unnamed objects.)
$ ldd /usr/bin/c-index-test-16.0.6 linux-vdso.so.1 (0x00007ffce2336000) libclang.so.13 => /lib64/libclang.so.13 (0x00007fb21ca18000) libclang-cpp.so.16 => /lib64/libclang-cpp.so.16 (0x00007fb218800000) libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fb218690000) libLLVM.so.16 => /lib64/libLLVM.so.16 (0x00007fb211200000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb210e00000) libc.so.6 => /lib64/libc.so.6 (0x00007fb210a00000) libclang-cpp.so.17 => /lib64/libclang-cpp.so.17 (0x00007fb20c800000) libLLVM.so.17 => /lib64/libLLVM.so.17 (0x00007fb205200000) libm.so.6 => /lib64/libm.so.6 (0x00007fb21c92f000) /lib64/ld-linux-x86-64.so.2 (0x00007fb21cb11000) libz.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libz.so.1.3 (0x00007fb218676000) liblzma.so.5 => /lib64/glibc-hwcaps/x86-64-v3/liblzma.so.5.4.5 (0x00007fb21863d000) libedit.so.0 => /lib64/libedit.so.0 (0x00007fb218601000) libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007fb2111c5000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb2111a0000)
This used to be an issue in the past, but by now both libLLVM and libclang-cpp use symbol versioning, so the different library versions shouldn't interfere.
c-index-test-16.0.6 thus will segfault when ran
#0 0x00007fccc253d319 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib64/libLLVM.so.17+0x3b3d319) #1 0x00007fccc253aed2 llvm::sys::RunSignalHandlers() (/lib64/libLLVM.so.17+0x3b3aed2) #2 0x00007fccc253db9b (/lib64/libLLVM.so.17+0x3b3db9b) #3 0x00007fccca23f190 __restore_rt (/lib64/libc.so.6+0x3f190) #4 0x00007fccc724587a (/lib64/libclang-cpp.so.17+0x124587a) #5 0x00007fccca2414e1 __cxa_finalize (/lib64/libc.so.6+0x414e1) #6 0x00007fccc719c0f7 (/lib64/libclang-cpp.so.17+0x119c0f7) Segmentation fault (core dumped)
It would be interesting to see (more) symbols here. The call to __cxa_finalize indicates that we're in cleanup prior to exiting the process. It might be that c-index-test is assuming that all libraries come from the same build and uses some mechanisms under the hood. (In reply to Shung-Hsi Yu from comment #1)
Seems like we'd need tools that depends on older version of llvm should link with /lib64/libclang.so.$ver from the corresponding llvm$ver-libclang package rather than the libclang package?
Then you couldn't install multiple versions of clang in parallel, unless we're willing to increase the SO version with every release. There has been some discussion about this upstream, but I think not increasing the SO version is actually the right thing, and it would be nice if it had been done so from the beginning. (Some Linux distributions have patched the build to produce libclang.so.1 from the beginning.) -- You are receiving this mail because: You are on the CC list for the bug.