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: 0707a17ecf/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.

(cherry picked from commit e0d6d05ce0)
This commit is contained in:
Lasse Collin 2024-06-04 23:59:29 +03:00
parent 92e5425979
commit 198271a6ed
No known key found for this signature in database
GPG Key ID: 38EE757D69184620
1 changed files with 30 additions and 4 deletions

View File

@ -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