Autotools-based build has always done this so this is for consistency.
However, the CMake build won't create the DEF file when building
for Cygwin or MSYS2 because in that context it should be useless.
(If Cygwin or MSYS2 is used to host building of normal Windows
binaries then the DEF file is still created.)
(cherry picked from commit c3b9dad07d3fd9319f88386b7095019bcea45ce1)
If common_w32res.rc is modified, the resource files need to be rebuilt.
In contrast, the liblzma*.map files truly are link dependencies.
(cherry picked from commit da4f275bd1c18b897e5c2dd0043546de3accce0a)
CMakeLists.txt was using xzdec_w32res.rc for both xzdec and lzmadec.
Fixes: 998d0b29536094a89cf385a3b894e157db1ccefe
(cherry picked from commit dc7b9f24b737e4e55bcbbdde6754883f991c2cfb)
The liblzma target was recently changed to link against Threads::Threads
with the PRIVATE keyword. I had forgotten that xz itself depends on
pthreads too due to pthread_sigmask(). Thus, the build broke when
building shared liblzma and pthread_sigmask() wasn't in libc.
Thanks to Peter Seiderer for the bug report.
Fixes: ac05f1b0d7cda1e7ae79775a8dfecc54601d7f1c
Fixes: https://github.com/tukaani-project/xz/issues/129#issuecomment-2204522994
(cherry picked from commit b3e53122f42796aaebd767bab920cf7bedf69966)
I had missed this simpler method before. It does create a dependency
so that if .in.h changes the copying is done again.
(cherry picked from commit de215a0517645d16343f3a5336d3df884a4f665f)
It was weird to add CMAKE_THREAD_LIBS_INIT in CMAKE_REQUIRED_LIBRARIES
only if CLOCK_MONOTONIC is available. Alternative would be to remove
the thread libs from CMAKE_REQUIRED_LIBRARIES after the check for
pthread_condattr_setclock() but keeping the libs should be fine too.
Then it's ready in case more pthread functions were wanted some day.
(cherry picked from commit e620f35097c0ad20cd76d8258750aa706758ced9)
In CMake, check_c_source_compiles() always links too. With
link-time optimization, unused functions may get omitted if
main() doesn't depend on them. Consider the following which
tries to check if somefunction() is available when <someheader.h>
has been included:
#include <someheader.h>
int foo(void) { return somefunction(); }
int main(void) { return 0; }
LTO may omit foo() completely because the program as a whole doesn't
need it and then the program will link even if the symbol somefunction
isn't available in libc or other library being linked in, and then
the test may pass when it shouldn't.
What happens if <someheader.h> doesn't declare somefunction()?
Shouldn't the test fail in the compilation phase already? It should
but many compilers don't follow the C99 and later standards that
prohibit implicit function declarations. Instead such compilers
assume that somefunction() exists, compilation succeeds (with a
warning), and then linker with LTO omits the call to somefunction().
Change the tests so that they are part of main(). If compiler accepts
implicitly declared functions, LTO cannot omit them because it has to
assume that they might have side effects and thus linking will fail.
On the other hand, if the functions/intrinsics being used are supported,
they might get optimized away but in that case it's fine because they
really are supported.
It is fine to use __attribute__((target(...))) for main(). At least
it works with GCC 4.9 to 14.1 on x86-64.
Reported-by: Sam James <sam@gentoo.org>
(cherry picked from commit 114cba69dbb96003e676c8c87a2e9943b12d065f)
This makes no difference yet because -lrt is currently the only option
that might be added to LIBS.
(cherry picked from commit 75ce4797d49621710e6da95d8cb91541028c6d68)
This way pthread options aren't passed to the linker when linking
against shared liblzma but they are still passed when linking against
static liblzma. (Also, one never needs the include path of the
threading library to use liblzma since liblzma's API headers
don't #include <pthread.h>. But <pthread.h> tends to be in the
default include path so here this change makes no difference.)
One cannot mix target_link_libraries() calls that use the scope
(PRIVATE, PUBLIC, or INTERFACE) keyword and calls that don't use it.
The calls without the keyword are like PUBLIC except perhaps when
they aren't, or something like that... It seems best to always
specify a scope keyword as the meanings of those three keywords
at least are clear.
(cherry picked from commit ac05f1b0d7cda1e7ae79775a8dfecc54601d7f1c)
This shouldn't make much difference in practice as on Windows
no flags are needed anyway and unitialized variable (when threading
is disabled) expands to empty. But it's clearer this way.
(cherry picked from commit 2aecffe0f0e14f3ef635e8cd7b405420f2385de2)
vcpkg doesn't specify the newline type so it should be fine to
use native newlines in liblzma.pc on Windows.
(cherry picked from commit 5ca96a93488d0f5a530c78b274cac317453807ff)
Now liblzma.pc can be relocatable only if using CMake >= 3.20
but that should be OK as now we shouldn't get broken liblzma.pc
if CMAKE_INSTALL_LIBDIR or CMAKE_INSTALL_INCLUDEDIR contain an
absolute path.
Thanks to Eli Schwartz.
(cherry picked from commit ebd155c3a1b87411edae06d3bdaa9659ec057522)
There is no need to make a similar change in configure.ac.
With Autoconf 2.72, the deprecated macro AC_PROG_CC_C99
is an alias for AC_PROG_CC which prefers a C11 compiler.
(cherry picked from commit 2178acf8a4d40a93e970cfcf9b807d5ef6c8da92)
liblzma_VERSION has never existed in the repository. xz_VERSION from
the project() command was used for liblzma SOVERSION so use xz_VERSION
here too.
The wrong variable did no harm in practice as PROJECT_VERSION
was used as the fallback. It has the same value as xz_VERSION.
Fixes: 7e3493d40eac0c3fa3d5124097745a70e15c41f6
(cherry picked from commit 1d3c61575fda0be6b2d50c9e32a343349d5cd5c0)
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 e0d6d05ce0d464e966c0669bbf869202a43cc2f7)
One has to pass -DENABLE_X86_ASM=ON to cmake to enable the
CRC assembly code. Autodetection isn't done. Looking at
CMAKE_SYSTEM_PROCESSOR might not work as it comes from uname
unless cross-compilation is done using a CMake toolchain file.
On top of this, if the code is run on modern processors that support
the CLMUL instruction, then the C code should be faster (but then
one should also be using a x86-64 build if possible).
(cherry picked from commit 24387c234b4eed1ef9a7eaa107391740b4095568)
This is disabled by default to match the default in Autotools.
Use -DUSE_DOXYGEN=ON to enable Doxygen usage.
This uses the update-doxygen script, thus this is under if(UNIX)
although Doxygen itself can run on Windows too.
(cherry picked from commit 64503cc2b76a388ced4ec5f68234a07f0dcddcd5)
This moves the tests section as is from CMakeLists.txt into
tests/tests.cmake. CMakeLists.txt now includes tests/tests.cmake
if the latter file exists.
Now it's possible to delete the whole "tests" directory and
building with CMake will still work normally, just without
the tests. This way the tests are readily available for those
who want them, and those who won't run the tests anyway have
a straightforward way to ensure that nothing from the "tests"
directory can affect the build process.
(cherry picked from commit aaff75c3486c4489ce88b0efb36b41cf138af7c3)
This is *NOT* done for security reasons even though the backdoor
relied on the ifunc code. Instead, the reason is that in this
project ifunc provides little benefits but it's quite a bit of
extra code to support it. The only case where ifunc *might* matter
for performance is if the CRC functions are used directly by an
application. In normal compression use it's completely irrelevant.
(cherry picked from commit 689ae2427342a2ea1206eb5ca08301baf410e7e0)
It doesn't support the __symver__ attribute or __asm__(".symver ...").
The generic symbol versioning can still be used since it only needs
linker support.
(cherry picked from commit c273123ed0ebaebf49994057a7fe98aae7f42c40)
This better matches what configure.ac does. For example, musl has
only basic symbol versioning support:
https://wiki.musl-libc.org/functional-differences-from-glibc.html#Symbol_versioning
configure.ac tries to enable symbol versioning only with glibc
so now CMake does the same.
(cherry picked from commit 2ad7fad67080e88fa7fc191f9d613d8b7add9c62)
Using __attribute__((__no_profile_instrument_function__)) on the ifunc
resolver works around a bug in GCC -fprofile-generate:
it adds profiling code even to ifunc resolvers which can make
the ifunc resolver crash at program startup. This attribute
was not introduced until GCC 7 and Clang 13, so ifunc won't
be used with prior versions of these compilers.
This bug was brought to our attention by:
https://bugs.gentoo.org/925415
And was reported to upstream GCC by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11411
The previous Linux Landlock feature test assumed that having the
linux/landlock.h header file was enough. The new feature tests also
requires that prctl() and the required Landlock system calls are
supported.
The original code was good enough for supporting GNU/Linux
and a few others but it wasn't very portable.
CMake doesn't support Solaris Studio's -xldscope=hidden.
If it ever does, things should still work with this commit
as Solaris Studio supports not only its own __global but also
the GNU C __attribute__((visibility("default"))). Support for the
attribute was added in 2007 to Sun Studio 12 compiler version 5.9.
-O3 doesn't seem useful for speed but it makes the code bigger.
CMake makes is difficult for users to simply override the
optimization level: CFLAGS / CMAKE_C_FLAGS aren't helpful because
they go before CMAKE_C_FLAGS_RELEASE. Of course, users can override
CMAKE_C_FLAGS_RELEASE directly but then they have to remember to
add also -DNDEBUG to disable assertions.
This commit changes -O3 to -O2 in CMAKE_C_FLAGS_RELEASE if and only if
CMAKE_C_FLAGS_RELEASE cache variable doesn't already exist. So if
a custom value is passed on the command line (or reconfiguring an
already-configured build), the cache variable won't be modified.
