From e0d6d05ce0d464e966c0669bbf869202a43cc2f7 Mon Sep 17 00:00:00 2001 From: Lasse Collin Date: Tue, 4 Jun 2024 23:59:29 +0300 Subject: [PATCH] CMake: Fix liblzma filename in Windows environments This is a mess because liblzma DLL outside Cygwin and MSYS2 is liblzma.dll instead of lzma.dll to avoid a conflict with lzma.dll from LZMA SDK. On Cygwin the name was "liblzma-5.dll" while "cyglzma-5.dll" would have been correct (and match what Libtool produces). MSYS2 likely was broken too as it uses the "msys-" prefix. This change has no effect with MinGW-w64 because with that the "lib" prefix was correct already. With MSVC builds this is a small breaking change that requires developers to adjust the library name when linking against liblzma. The liblzma.dll name is kept as is but the import library and static library are now lzma.lib instead of liblzma.lib. This is helpful when using pkgconf because "pkgconf --msvc-syntax --libs liblzma" outputs "lzma.lib" (it's converted from "-llzma" in liblzma.pc). It would be easy to keep the liblzma.lib naming but the pkgconf compatibility seems worth it in the long run. The lzma.lib name is compatible with MinGW-w64 too as -llzma will find also lzma.lib. vcpkg had been patching CMakeLists.txt this way since 2022 but I learned this only recently. The reasoning for the patch makes sense, and while this is a small breaking change with MSVC, it seems like a decent compromise as it keeps the DLL name the same. 2022 patch in vcpkg: https://github.com/microsoft/vcpkg/blob/0707a17ecf1466d64cf1a3c1ee18c8ff02aadb2d/ports/liblzma/win_output_name.patch See the discussion: https://github.com/microsoft/vcpkg/pull/39024 Thanks to Vincent Torri for confirming the naming issue on Cygwin. --- CMakeLists.txt | 34 ++++++++++++++++++++++++++++++---- 1 file changed, 30 insertions(+), 4 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 80183b05..f18161d9 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -1317,12 +1317,38 @@ set_target_properties(liblzma PROPERTIES SOVERSION "${xz_VERSION_MAJOR}" VERSION "${xz_VERSION}" - # It's liblzma.so or liblzma.dll, not libliblzma.so or lzma.dll. - # Avoid the name lzma.dll because it would conflict with LZMA SDK. - PREFIX "" - IMPORT_PREFIX "" + # The name liblzma a mess because in many places "lib" is just a prefix + # and not part of the actual name. (Don't name a new library this way!) + # Cygwin uses "cyg", MSYS2 uses "msys-", and some platforms use no prefix. + # However, we want to avoid lzma.dll on Windows as that would conflict + # with LZMA SDK. liblzma has been liblzma.dll on Windows since the + # beginning so try to stick with it. + # + # Up to XZ Utils 5.6.2 we set PREFIX and IMPORT_PREFIX properties to "" + # while keeping the default "liblzma" OUTPUT_NAME that was derived from + # the target name. But this broke naming on Cygwin and MSYS2. + # + # Setting OUTPUT_NAME without the "lib" prefix means that CMake will add + # the platform-specific prefix as needed. So on most systems CMake will + # add "lib" but on Cygwin and MSYS2 the naming will be correct too. + # + # On Windows, CMake uses the "lib" prefix with MinGW-w64 but not with + # other toolchains. Those those need to be handled specially to get + # the DLL file named liblzma.dll instead of lzma.dll. + OUTPUT_NAME "lzma" ) +if(WIN32 AND NOT MINGW) + # Up to XZ Utils 5.6.2 and building with MSVC, we produced liblzma.dll + # and liblzma.lib. The downside of liblzma.lib is that it's not + # compatible with pkgconf usage. liblzma.pc contains "-llzma" which + # "pkgconf --msvc-syntax --libs liblzma" converts to "lzma.lib". + # So as a compromise, we can keep the liblzma.dll name but the import + # library and static liblzma need to be named lzma.lib so that pkgconf + # can be used with MSVC. (MinGW-w64 finds both names with "-llzma".) + set_target_properties(liblzma PROPERTIES RUNTIME_OUTPUT_NAME "liblzma") +endif() + # Create liblzma-config-version.cmake. # # FIXME: SameMajorVersion is correct for stable releases but it is wrong