Comment # 2 on bug 1219405 from Aaron Puchert

(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.)