On 12/28/2018 11:01 AM, Waleed Hamra via blfs-support wrote:
Hello guys;
I updated my LLVM/Clang from 6.0.1 to 7.0.1, and many things broke.
Including mesa's glx amongst others.
I noticed that I have tons of libraries that specifically depend on
libLLVM-6.0.so, and not on libLLVM.so, which will always point to
whichever is the latest installed version.
On my system, I do see
$ ldd ./libva-glx.so
...
libLLVM-6.0.so => /usr/lib/libLLVM-6.0.so
...
but I still have /usr/lib/libLLVM-6.0.so even though I installed llvm-7.0.1.
I can recompile the affected packages, they're not too many, but I have
a couple of questions first.
I did some limited testing with creating a symlink from libLLVM-6.0.so
into libLLVM.so, and the few programs I tried to run which were linking
to it, ran properly. Can this screw something up later on?
Can I force programs to link against libLLVM.so instead of the versioned
ones? As I was doing my little research, I ran ldd on all my libraries
looking for broken links, and found a bunch that were also linking to
versioned boost libraries. Is there any cmake/configure wizardry to
alter this unfriendly behaviour?
When building, the linker looks at the .so file and uses that symlink to
determine the proper library. It adds a link to the file .so.N to the
target. Then when running, the .so.N file is used. That is generally a
symlink to .so.N.MMM. When updating, the .so.N and .so.N.MMM are not
removed. If the versions are not changed, they are overwritten, but
that means that the API has not changed.
$ ll /usr/lib/libLLVM-*
-rwxr-xr-x 1 43106632 Dec 22 /usr/lib/libLLVM-6.0.so
lrwxrwxrwx 1 14 Oct 8 /usr/lib/libLLVM-6.0.1.so -> libLLVM-6.0.so
-rwxr-xr-x 1 44545224 Dec 22 /usr/lib/libLLVM-7.so
lrwxrwxrwx 1 12 Dec 21 /usr/lib/libLLVM-7.0.1.so -> libLLVM-7.so
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
