Wrong libLLVM symbolic links generated for 18.1

[finagolfin]

I'm guessing this is related to bumping the minor version for the first time in a long time:

> ls -l /data/data/com.termux/files/usr/lib/libLLVM*so*
lrwxrwxrwx 1 u0_a318 u0_a318        18 Mar  9 20:46 /data/data/com.termux/files/usr/lib/libLLVM-18.so -> libLLVM.so.18.1
-rw------- 1 u0_a318 u0_a318 114521080 Mar  9 12:39 /data/data/com.termux/files/usr/lib/libLLVM.so

We build with -DLLVM_LINK_LLVM_DYLIB=ON to make sure this shared library is included, which is then linked against by the Rust compiler and so on also. I think the relevant CMake config is here, which I notice @tstellar recently modified.

[tstellar]

What should the symlinks look like? Also, in my builds libLLVM.so is a symlink to libLLVM.so.18.1, I'm not sure why you are seeing libLLVM.so as a regular file.

[finagolfin]

This is what they look like for the current LLVM 17 package that we distribute, built with the exact set of CMake build flags I linked above:

> ls -l data/data/com.termux/files/usr/lib/libLLVM*so
lrwxrwxrwx 1 u0_a318 u0_a318        18 Nov 28 21:26 data/data/com.termux/files/usr/lib/libLLVM-17.0.6.so -> libLLVM-17.so
-rw------- 1 u0_a318 u0_a318 115962784 Nov 28 21:26 data/data/com.termux/files/usr/lib/libLLVM-17.so
lrwxrwxrwx 1 u0_a318 u0_a318        18 Nov 28 21:26 data/data/com.termux/files/usr/lib/libLLVM.so -> libLLVM-17.so

What do you see after building LLVM 18 with the shared library?

[tstellar]

$ ls -l libLLVM*so
lrwxrwxrwx. 1 fedora fedora 15 Mar  9 21:04 libLLVM-18.so -> libLLVM.so.18.1
lrwxrwxrwx. 1 fedora fedora 15 Mar  9 21:04 libLLVM.so -> libLLVM.so.18.1

[h-vetinari]

In our builds on conda-forge, #82647 (resp. 4cc7a75) only fixed the linux side, but on OSX the result is still:

UserWarning: file $PREFIX/lib/libLLVM-18.dylib is a symlink with no target

(this is in a setting where the unversioned libLLVM.dylib intentionally isn't available yet, but libLLVM.18.1.dylib is)

[tstellar]

@h-vetinari Can you post the output of ls -l libLLVM*dylib* from the install directory?

[finagolfin]

@tstellar, I assume the libLLVM.so.18.1 library exists for you? I took a look at the Android build log and it shows exactly the two files I listed being installed, so it appears this is the result of the LLVM build, not any post-build modifications in our Termux packaging scripts.

What build flags do you pass in to CMake when building LLVM? I've linked our LLVM-specific flags above and we use more flags for all CMake builds.

I presume the problem is the difference in build flags or some platform-specific CMake issue.

[h-vetinari]

@h-vetinari Can you post the output of ls -l libLLVM*dylib* from the install directory?

Certainly:

+ ls -l $PREFIX/lib/libLLVM*dylib*
lrwxr-xr-x  1 runner  staff         18 Mar 12 06:00 $PREFIX/lib/libLLVM-18.dylib -> libLLVM.dylib.18.1
-rwxr-xr-x  1 runner  staff  128049832 Mar 12 05:56 $PREFIX/lib/libLLVM.18.1.dylib
lrwxr-xr-x  1 runner  staff         18 Mar 12 06:00 $PREFIX/lib/libLLVM.dylib -> libLLVM.18.1.dylib

The issue is the symlink pointing to libLLVM-18.dylib -> libLLVM.dylib.18.1 (note 18.1 at the end) vs. the library being called libLLVM.18.1.dylib (i.e. version in between)

[tstellar]

@finagolfin Just to be clear the problem you are seeing is that libLLVM.so is not a symlink to libLLVM.so.18.1 ?

[tstellar]

@h-vetinari Is there any reason why you can't link against libLLVM.18.1.dylib ?

[h-vetinari]

@h-vetinari Is there any reason why you can't link against libLLVM.18.1.dylib ?

No there isn't, but the point is that the CMake build as-is generates a broken symlink, and I'd prefer to fix it in LLVM rather than having to carry a manual fix.

[finagolfin]

Just to be clear the problem you are seeing is that libLLVM.so is not a symlink to libLLVM.so.18.1 ?

Yep, that would be one way to fix it. We link our Rust compiler build against libLLVM-18.so, so obviously that is broken now. I will manually fix it in our build script for now, but like @h-vetinari, I think it would be better if the LLVM CMake config generated these properly again in future releases.