[llvm-shlib] Fix the version naming style of libLLVM for Windows #85710
Conversation
This reverts the changes from 91a3846 for Windows targets. The changes in that commit don't work as expected for Windows targets (those parts of llvm_add_library don't quite behave the same for Windows), while the previous status quo (producing a library named "libLLVM-<major>.dll") is the defacto standard way of doing versioned library names there, contrary to on Unix. After that commit, the library always ended up named "libLLVM.dll", executables linking against it would reference "libLLVM.dll", and "libLLVM-<major>.dll" was provided as a symlink. Thus revert this bit back to as it were, so that executables actually link against a versioned libLLVM, and no separate symlink is needed. The only thing that might be improved compared to the status quo as it was before these changes, is that the import library is named "lib/libLLVM-<major>.dll.a", while the common style would be to name it plainly "lib/libLLVM.dll.a" (even while it produces references to "libLLVM-<major>.dll", but none of these had that effect for Windows targets. (As a side note, the llvm-shlib library can be built for MinGW, but not currently in MSVC configurations.)
|
/cherry-pick cb2ca23 |
|
Failed to cherry-pick: cb2ca23 https://github.com/llvm/llvm-project/actions/runs/8338749880 Please manually backport the fix and push it to your github fork. Once this is done, please create a pull request |
…m#85710) This reverts the changes from 91a3846 for Windows targets. The changes in that commit don't work as expected for Windows targets (those parts of llvm_add_library don't quite behave the same for Windows), while the previous status quo (producing a library named "libLLVM-<major>.dll") is the defacto standard way of doing versioned library names there, contrary to on Unix. After that commit, the library always ended up named "libLLVM.dll", executables linking against it would reference "libLLVM.dll", and "libLLVM-<major>.dll" was provided as a symlink. Thus revert this bit back to as it were, so that executables actually link against a versioned libLLVM, and no separate symlink is needed. The only thing that might be improved compared to the status quo as it was before these changes, is that the import library is named "lib/libLLVM-<major>.dll.a", while the common style would be to name it plainly "lib/libLLVM.dll.a" (even while it produces references to "libLLVM-<major>.dll", but none of these had that effect for Windows targets. (As a side note, the llvm-shlib library can be built for MinGW, but not currently in MSVC configurations.) (cherry picked from commit cb2ca23)
|
/pull-request #85746 |
|
As a headsup to @lazka and @mati865 wrt msys2 packaging: LLVM 18.1.0 and 18.1.1 had the llvm dylib erroneously named I didn't include any extra backwards compat symlink named I guess you can add a temporary symlink/copy within the msys2 packaging of later 18.1.x to smooth out this - but I felt it's the best tradeoff to not provide a symlink on the LLVM side here by default, as symlinks often end up as duplicate copies on Windows. (This issue with symlinks ending up as large duplicate files can be noticed in the release packages at https://github.com/mstorsjo/llvm-mingw/releases - the |
|
Thanks. Note that it's Maybe we'll leave it as is, and revert to the upstream schema with 19(?) |
Oh, ok, I see - yeah in that case, if you've already patched around it, this isn't an issue at all. The earlier changes slipped past me as they didn't break the build for me. |
|
They did break llvm-config (which is used by meson) afair, but I think that's not included in llvm-mingw. We would have reported it eventually, but there seemed various things in flux re versions already. |
Oh, right, that's a good point. Let me check whether we'd need to tweak that along with this change here. |
|
If its like with v17 it should be good I think |
Yep, I checked, and e.g. For the unix targets, it should still work as we do provide |
…m#85710) This reverts the changes from 91a3846 for Windows targets. The changes in that commit don't work as expected for Windows targets (those parts of llvm_add_library don't quite behave the same for Windows), while the previous status quo (producing a library named "libLLVM-<major>.dll") is the defacto standard way of doing versioned library names there, contrary to on Unix. After that commit, the library always ended up named "libLLVM.dll", executables linking against it would reference "libLLVM.dll", and "libLLVM-<major>.dll" was provided as a symlink. Thus revert this bit back to as it were, so that executables actually link against a versioned libLLVM, and no separate symlink is needed. The only thing that might be improved compared to the status quo as it was before these changes, is that the import library is named "lib/libLLVM-<major>.dll.a", while the common style would be to name it plainly "lib/libLLVM.dll.a" (even while it produces references to "libLLVM-<major>.dll", but none of these had that effect for Windows targets. (As a side note, the llvm-shlib library can be built for MinGW, but not currently in MSVC configurations.) (cherry picked from commit cb2ca23)
…m#85710) This reverts the changes from 91a3846 for Windows targets. The changes in that commit don't work as expected for Windows targets (those parts of llvm_add_library don't quite behave the same for Windows), while the previous status quo (producing a library named "libLLVM-<major>.dll") is the defacto standard way of doing versioned library names there, contrary to on Unix. After that commit, the library always ended up named "libLLVM.dll", executables linking against it would reference "libLLVM.dll", and "libLLVM-<major>.dll" was provided as a symlink. Thus revert this bit back to as it were, so that executables actually link against a versioned libLLVM, and no separate symlink is needed. The only thing that might be improved compared to the status quo as it was before these changes, is that the import library is named "lib/libLLVM-<major>.dll.a", while the common style would be to name it plainly "lib/libLLVM.dll.a" (even while it produces references to "libLLVM-<major>.dll", but none of these had that effect for Windows targets. (As a side note, the llvm-shlib library can be built for MinGW, but not currently in MSVC configurations.)
This reverts the changes from 91a3846 for Windows targets. The changes in that commit don't work as expected for Windows targets (those parts of llvm_add_library don't quite behave the same for Windows), while the previous status quo (producing a library named "libLLVM-.dll") is the defacto standard way of doing versioned library names there, contrary to on Unix.
After that commit, the library always ended up named "libLLVM.dll", executables linking against it would reference "libLLVM.dll", and "libLLVM-.dll" was provided as a symlink.
Thus revert this bit back to as it were, so that executables actually link against a versioned libLLVM, and no separate symlink is needed.
The only thing that might be improved compared to the status quo as it was before these changes, is that the import library is named "lib/libLLVM-.dll.a", while the common style would be to name it plainly "lib/libLLVM.dll.a" (even while it produces references to "libLLVM-.dll", but none of these had that effect for Windows targets.
(As a side note, the llvm-shlib library can be built for MinGW, but not currently in MSVC configurations.)