llvm-shlib: Fix libLLVM-${MAJOR}.so symlink on MacOS

[tstellar]

This is a partial revert of 10c48a7 with a fix for the symlink target name on MacOS

See #84637

[nikic]

LGTM

[mstorsjo]

This broke building the dylib for mingw platforms, see e.g. https://github.com/mstorsjo/llvm-mingw/actions/runs/8303983325/job/22728993479:

CMake Error:
  Error evaluating generator expression:

    $<TARGET_SONAME_FILE_NAME:LLVM>

  TARGET_SONAME_FILE is not allowed for DLL target platforms.

Could we revert this until we sort it out, to get my builds back to green?

[tstellar]

@mstorsjo What symlinks / library names do you expect for mingw?

[mstorsjo]

@mstorsjo What symlinks / library names do you expect for mingw?

I see the other recent changes here have regressed how libLLVM is set up for mingw, #82660 and/or #79376), so I see this behaves worse for 18.1.0 final, while it was ok in earlier RCs.

The ideal situation for mingw is like it was before all these changes; bin/libLLVM-18.dll coupled with lib/libLLVM.dll.a, no symlinks needed.

[tstellar]

@mstorsjo What files are currently produced? Is there a libLLVM.dll.18.1 file ?

[mstorsjo]

@mstorsjo What files are currently produced? Is there a libLLVM.dll.18.1 file ?

Currently, before this change, the build produces bin/libLLVM.dll and lib/libLLVM.dll.a, and on install it adds bin/libLLVM-19git.dll as a symlink to bin/libLLVM.dll. (And currently after this change, the build fails at the cmake stage.)

[tstellar]

Can you try this fix: #85554

[mstorsjo]

Can you try this fix: #85554

Thanks, this fixes the immediate build break.

I can look into fixing the rest of the situation later when I have time (in a day or two). Previously, the effective “soname” on windows was libLLVM-18.dll, but now it is libLLVM.dll, entirely lacking the version component. (The versioned libLLVM-18.dll is installed as a symlink, but the other binaries reference the unversioned name.)