Build: Use AC_LINK_IFELSE instead of -Werror

AC_COMPILE_IFELSE needed -Werror because Clang <= 14 would merely
warn about the unsupported attribute and implicit function declaration.
Changing to AC_LINK_IFELSE handles the implicit declaration because
the symbol __crc32d is unlikely to exist in libc.

Note that the other part of the check is that #include <arm_acle.h>
must work. If the header is missing, most compilers give an error
and the linking step won't be attempted.

Avoiding -Werror makes the check more robust in case CFLAGS contains
warning flags that break -Werror anyway (but this isn't the only check
in configure.ac that has this problem). Using AC_LINK_IFELSE also makes
the check more similar to how it is done in CMakeLists.txt.

Build: Sync the compile check changes from CMakeLists.txt

It's nice to keep these in sync. The use of main() will later allow
AC_LINK_IFELSE usage too which may avoid the more fragile -Werror.

CMake: Not experimental anymore

While the CMake support has gotten a lot less testing than
the Autotools-based build, the supported features should now
be equal. The output may differ slightly, for example,
liblzma.pc may have

    Libs.private: -pthread -lpthread

with Autotools on GNU/Linux. CMake doesn't put any options
in Libs.private because on modern glibc the pthread functions
are in libc. The options options aren't required to link static
liblzma into an application.

Autotools-based build doesn't generate or install
lib/cmake/liblzma-*.cmake files. This means that on most
platforms one cannot rely on

    find_package(liblzma 5.2.5 REQUIRED CONFIG)

or such finding those files.

CMake: Use configure_file() to copy a file

I had missed this simpler method before. It does create a dependency
so that if .in.h changes the copying is done again.

CMake: Always add pthread flags into CMAKE_REQUIRED_LIBRARIES

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.

CMake: Tweak comments

Co-authored-by: Lasse Collin <lasse.collin@tukaani.org>

CMake: Edit white space for consistency

CMake: Fix three checks if building with -flto

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>

CMake: Use MATCHES instead of multiple STREQUAL

CMake: Improve the comment about LIBS

CMake: Fix a typo in a message

It was spotted with codespell.

Document CMake options in INSTALL

CI: Don't omit crc32 from the list with CMake anymore

XZ_CHECKS accepts it but works without too.

CI: Workaround buggy config.guess on Ubuntu 22.04LTS and 24.04LTS

Check for the wrong triplet from config.guess and override it with
the --build option on the configure command line. Then i386 assembly
autodetection will work.

These Ubuntu versions (and as of writing, also Debian unstable)
ship config.guess version 2022-01-09 which contains a bug that
was fixed in version 2022-05-08. It results in a wrong configure
triplet when using CC="gcc -m32" to build i386 binaries.

Upstream fix:
https://git.savannah.gnu.org/cgit/config.git/commit/?id=f56a7140386d08a531bcfd444d632b28c61a6329

More information:
https://mail.gnu.org/archive/html/config-patches/2022-05/msg00003.html

CI: Use CC="gcc -m32" to get i386 compiler on x86-64

The old method put it in CFLAGS which is a wrong place because
config.guess doesn't read CFLAGS.

CI: Let CMake use the CC environment variable

CC from environment is used to initialize CMAKE_C_COMPILER so
setting CMAKE_C_COMPILER explicitly isn't needed.

The syntax in ci_build.bash was broken in case one wished to put
spaces in CC.

CMake: Add autodetection for 32-bit x86 CRC assembly usage

CMake: Move option(XZ_ASM_I386) downwards a few lines

DOS: Update Makefile and config.h for the CRC changes

liblzma: Tidy up crc_common.h

Prefix ARM64_RUNTIME_DETECTION with CRC_ and reorder it to be with
the other ARM64-specific lines. That macro isn't used outside this
file.

ARM64 CLMUL implementation doesn't exist yet and thus CRC64_ARM64_CLMUL
isn't used anywhere yet.

It's not ideal that the single-letter CRC utility macros are here
as they pollute the namespace of the LZ encoder files. Those could
be moved their own crc_macros.h like they were in 5.2.x but in practice
this is fine enough already.

liblzma: Move lzma_crcXX_table[][] declarations to crc_common.h

LZ encoder needs lzma_crc32_table[0] but otherwise those tables
are private to the CRC code. In contrast, the other things in
check.h are needed in several places.

liblzma: Make 32-bit x86 CRC assembly co-exist with CLMUL

Now runtime detection of CLMUL support can pick between the CLMUL and
the generic assembly implementations. Whatever overhead this has for
builds that omit CLMUL completely isn't important because builds for
any non-ancient system is likely to include the CLMUL code too.

Handle the CRC tables in crcXX_fast.c files because now these files
are built even when assembly code is used.

If 32-bit x86 assembly is enabled then it will always be built even
if compiler flags were such that CLMUL would be allowed unconditionally.
That is, runtime detection will be used anyway. This keeps the build
rules simpler.

In LZ encoder, build and use lzma_lz_hash_table[256] if CLMUL CRC
is used without runtime detection. Previously this wasn't needed
because crc32_table.c included the lzma_crc32_table[][] in the build
unless encoder support had been disabled. Including an 8 KiB table
was silly when only 1 KiB is actually used. So now liblzma is 7 KiB
smaller if CLMUL is enabled without runtime detection.

liblzma: CRC: Rename crcXX_generic to lzma_crcXX_generic

This prepares for the possibility that lzma_crc32_generic and
lzma_crc64_generic are extern functions.

CMake: Define HAVE_CRC_X86_ASM when 32-bit x86 CRC assembly is used

Build: Define HAVE_CRC_X86_ASM when 32-bit x86 CRC assembly is used

This makes it easier to determine when the CRC tables are needed.

CI: Update to the new renamed options in CMakeLists.txt

CMake: Add XZ_EXTERNAL_SHA256

CMake: Move threading detection a few lines up

It feels clearer this way, and when support for external SHA-256
is added, this will keep the order of the library detection the
same as in configure.ac (check for pthreads before libmd) although
it shouldn't matter in practice.

CMake: Move the sandbox code out of the liblzma section

Sandboxing is for the command line tools, not liblzma.
No functional changes.

CMake: Keep existing options in LIBS when adding -lrt

This makes no difference yet because -lrt is currently the only option
that might be added to LIBS.

CMake: Don't install scripts if the xz tool isn't built

The scripts need the xz tool.

CMake: Add XZ_TOOL_XZDEC and XZ_TOOL_LZMADEC

CMake: Add XZ_TOOL_LZMAINFO

CMake: Add XZ_TOOL_XZ

Windows: Drop Visual Studio 2013 support

This simplifies things a little. Building liblzma with VS2013 probably
still worked but building the command line tools was not supported.

Microsoft ended support for VS2013 on 2024-04.

CMake: Add XZ_TOOL_SCRIPTS

CMake: Add XZ_DOC

CMake: Refactor XZ_SYMBOL_VERSIONING to match configure.ac

Make the available options and their behavior match
--enable-symbol-versions in configure.ac.

Don't enable symbol versions on Linux if not using glibc. Previously
the generic variant was selected on Microblaze or if using NVHPC
without checking that libc is glibc.

Leave the cache variable to "auto" or "yes" if that was specified
instead of setting it to the autodetected value by default. A downside
is that one cannot easily see which variant the autodetection code
has selected. The same applies to XZ_SANDBOX and XZ_THREADS though.

CMake: Use the same option list for XZ_THREADS as in configure.ac

Also clarify that "yes" will fail if no threading support is found.
If no threading is wanted, it has to be disabled manually.

configure.ac doesn't behave this way at the moment. Instead it
assumes pthreads to be present if not targeting Windows. If pthreads
actually are missing, the build fails later.

CMake: Use the same option list for XZ_SANDBOX as in configure.ac

It's simpler to document this way.

CMake: Fix indentation

CMake: Add warning options for GCC and Clang

The list was copied from configure.ac and should be kept in sync.
(Pretend that the deleted comment in CMakeLists.txt didn't exist.)

There is no need to add equivalent of --enable-werror as CMake >= 3.24
supports -DCMAKE_COMPILE_WARNING_AS_ERROR=ON.

CMake: Use \040 instead of \x20 for a space

This is for consistency with 4c81c9611f8b2e1ad65eb7fa166afc570c58607e
where \040 has to be used because \0x20F gets interpret at three hex
digits. Octals escapes are never longer than three digits.

CMake: Add XZ_ASSUME_RAM

CMake: Rename liblzma_INSTALL_CMAKEDIR to XZ_INSTALL_CMAKEDIR

CMake: Refactor ADDITIONAL_CHECK_TYPES to XZ_CHECKS

Now "crc32" is in the list too for completeness but it doesn't
actually have any effect. The description of the cache variable
says that "crc32 is always built" so it should be clear enough.

CMake: Rename the cache variable POSIX_SHELL to XZ_POSIX_SHELL

We still need the variable POSIX_SHELL for configure_file()
but it doesn't need to be a cache variable.

CMake: Rename ENCODERS and DECODERS to use XZ_ prefix

CMake: Rename MATCH_FINDERS to XZ_MATCH_FINDERS

CMake: Rename SYMBOL_VERSIONING to XZ_SYMBOL_VERSIONING

CMake: Rename ENABLE_THREADS to XZ_THREADS

CMake: Rename ENABLE_SANDBOX to XZ_SANDBOX

CMake: Rename ENABLE_X86_ASM to XZ_ASM_I386

CMake: Rename CREATE_XZ_SYMLINKS to XZ_TOOL_SYMLINKS

This only affects the names unxz and xzcat. The xz-prefixed script
symlinks (xzfgrep and such) are always created if scripts are enabled.

CMake: Rename CREATE_LZMA_SYMLINKS to XZ_TOOL_LZMA_SYMLINKS

Update the description too.

It affects creation of not only the legacy lzma, unlzma, lzcat symlinks
but also lzgrep and other legacy names for the scripts. The last
LZMA Utils release was made in 2008 but these names are still used
in some places to handle .lzma files.

CMake: Rename ALLOW_ARM64_CRC32 to XZ_ARM64_CRC32

Update description too.

CMake: Rename ALLOW_CLMUL_CRC to XZ_CLMUL_CRC

Update description too.

CMake: Rename ENABLE_DOXYGEN to XZ_DOXYGEN

CMake: Rename LZIP_DECODER to XZ_LZIP_DECODER

CMake: Rename MICROLZMA_ENCODER/DECODER to XZ_MICROLZMA_ENCODER/DECODER

CMake: Rename ENABLE_SMALL to XZ_SMALL

CMake: Rename ENABLE_NLS to XZ_NLS

Also update the description to mention that this affects installation
of translated man pages too.

Prefixing the cache variables with the project name helps if
the package is used as a subproject in another package.
It also makes the package-specific options group more nicely
in ccmake and cmake-gui.

CMake: Link Threads::Threads as PRIVATE to liblzma

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.

CMake: Add empty lines

CMake: Use CMAKE_THREAD_LIBS_INIT in liblzma.pc only with pthreads

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.

Update THANKS

CMake: Use native newlines in liblzma.pc

vcpkg doesn't specify the newline type so it should be fine to
use native newlines in liblzma.pc on Windows.

CMake: Use relative paths in liblzma.pc if possible

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.

Revert "CMake: Set only "prefix" as an absolute path in liblzma.pc"

This reverts commit 5d1c649ba9eb7a5b9371252ebfbc2911dc774e69.

While CMAKE_INSTALL_<dir> tend to be relative paths, they don't need
to be. Thus the commit was broken. A fancier method is required.

Thanks to Eli Schwartz for the bug report and explanation.

liblzma: CRC CLMUL: Omit is_arch_extension_supported() when not needed

On E2K the function compiles only due to compiler emulation but the
function is never used. It's cleaner to omit the function when it's
not needed even though it's a "static inline" function.

Thanks to Ilya Kurdyukov.

liblzma: x86 CLMUL CRC: Rewrite

It's faster with both tiny and large buffers and doesn't require
disabling any sanitizers. With large buffers the extra speed is
from folding four 16-byte chunks in parallel.

The 32-bit x86 with MSVC reportedly still needs a workaround.
Now the simpler "__asm mov ebx, ebx" trick is enough but it
needs to be in lzma_crc64() instead of crc64_arch_optimized().
Thanks to Iouri Kharon for testing and the fix.

Thanks to Ilya Kurdyukov for testing the speed with aligned and
unaligned buffers on a few x86 processors and on E2K v6.

Thanks to Sam James for general feedback.

Fixes: https://github.com/tukaani-project/xz/issues/112
Fixes: https://github.com/tukaani-project/xz/issues/122

sysdefs.h: Add alignas

liblzma: Use a single macro to select CLMUL CRC to build

This way it's clearer that two things cannot be selected
at the same time.

liblzma: CRC32 CLMUL: Refactor the constants and simplify

By using modulus scaled constants, the final reduction can
be simplified.

liblzma: CRC64 CLMUL: Refactor the constants

Now it refers to crc_clmul_consts_gen.c. vfold8 was renamed to mu_p
and the p no longer has the lowest bit set (it makes no difference
as the output bits it affects are ignored).

liblzma: Add crc_clmul_consts_gen.c

It's a standalone program that prints the required constants.
It's won't be a part of the normal build of the package.

liblzma: Remove CRC_USE_GENERIC_FOR_SMALL_INPUTS

It was already commented out.

liblzma: Remove crc_attr_no_sanitize_address

It's not enough to silence the address sanitizer. Also memory and
thread sanitizers would need to be silenced. They, at least currently,
aren't smart enough to see that the extra bytes are discarded from
the xmm registers by later instructions.

Valgrind is smarter, possibly because this kind of code isn't weird
to write in assembly. Agner Fog's optimizing_assembly.pdf even mentions
this idea of doing an aligned read and then discarding the extra
bytes. The sanitizers don't instrument assembly code but Valgrind
checks all code.

It's better to change the implementation to avoid the sanitization
attributes which also look scary in the code. (Somehow they can look
more scary than __asm__ which is implictly unsanitized.)

See also:
https://github.com/tukaani-project/xz/issues/112
https://github.com/tukaani-project/xz/issues/122

Revert "Build: Temporarily disable CRC CLMUL to silence OSS Fuzz"

This reverts commit 9f1a6d6f9a258886933a22239a5b81af34b28199.

CMake: Prefer C11 with a fallback to C99

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.

Update THANKS

Tests: Improve the CRC32 test

A similar one was already there for CRC64 but nowadays also CRC32
has a CLMUL implementation, so it's good to test it better too.

xz: Fix white space

liblzma: Fix a typo in a comment

Thanks to Sam James for spotting it.

Fixes: f644473a211394447824ea00518d0a214ff3f7f2

liblzma: Fix a comment indentation

liblzma: Fix white space

tuklib: __STDC_VERSION__ in C23 is 202311

Fix typos

Closes: https://github.com/tukaani-project/xz/pull/124

tuklib_integer: Fix building on OpenBSD/sparc64 that uses GCC 4.2

GCC 4.2 doesn't have __builtin_bswap16() and friends so tuklib_integer.h
tries to use OS-specific byte swap methods instead. On OpenBSD those
macros are swap16/32/64 instead of bswap16/32/64 like on other *BSDs
and Darwin.

An alternative to "#ifdef __OpenBSD__" could be "#ifdef swap16" as it
is a macro. But since OpenBSD seems to be a special case under this
special case of "*BSDs and Darwin", checking for __OpenBSD__ seems
the more conservative choice now.

Thanks to Christian Weisgerber and Brad Smith who both submitted
the same patch a few hours apart.

Co-authored-by: Christian Weisgerber <naddy@mips.inka.de>
Co-authored-by: Brad Smith <brad@comstyle.com>
Closes: https://github.com/tukaani-project/xz/pull/126

liblzma: Add ARM64 CRC32 instruction support detection on OpenBSD

The C code is from Christian Weisgerber, I merely reordered the OSes.
Then I added the build system checks without testing them.

Also thanks to Brad Smith who submitted a similar patch on GitHub
a few hours after Christian had sent his via email.

Co-authored-by: Christian Weisgerber <naddy@mips.inka.de>
Closes: https://github.com/tukaani-project/xz/pull/125

Update THANKS

CMake: Include the "alpha" or "beta" suffix in PACKAGE_VERSION

This way the version string gets into xzgrep and other scripts
in full and also into liblzma.pc.

For the project() command, a suffixless string is required though.

CMake: Fix wrong version variable

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

CMake: Set only "prefix" as an absolute path in liblzma.pc

CMake provides variables that are relative to CMAKE_INSTALL_PREFIX
so use them instead of repeating the full path.

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.

Fix version.sh compatiblity with Solaris

The ancient /bin/tr on Solaris doesn't support '\n'.
With /usr/xpg4/bin/tr it works but it might not be in PATH.

Another problem was that sed was given input that didn't have a newline
at the end. Text files must end with a newline to be portable.

Fix both problems:

  - Handle multiline input within sed itself to avoid one tr invocation.
    The default sed even on Solaris does understand \n.

  - Use octals in tr -d. \012 works for ASCII "line feed", it's even
    used as an example in the Solaris man page. But we must strip
    also ASCII "carriage return" \015 and EBCDIC "next line" \025.
    The EBCDIC case got handled with \n previously. Stripping \012
    and \015 on EBCDIC system won't matter as those control chars
    won't be present in the string in the first place.

An awk-based solution could be an alternative but it might need
special casing on Solaris to used nawk instead of awk. The changes
in this commit are smaller and should have a smaller risk for
regressions. It's also possible that version.sh will be dropped
entirely at some point.

CI: Don't require po4a on Solaris

CI: Use set -e on Solaris too

CMake: Install liblzma.pc even with MSVC

I had misunderstood that it wouldn't be useful with MSVC.
vcpkg had been installing liblzma.pc with custom rules since 2020,
years before liblzma.pc support was added to CMakeLists.txt.

See:
https://github.com/microsoft/vcpkg/blob/eb895b95aac6fd7485373702f29f508c42a180a0/ports/liblzma/portfile.cmake
https://github.com/microsoft/vcpkg/pull/39024#issuecomment-2145064670

ci: don't pin official GH actions via commit, just tag

There's no real value in doing it via commit for official GH actions. We
can keep using pinned commits for unofficial actions. It's hassle for no
gain.

Maybe going forward we can limit this further by only being paranoid
for the jobs with any access to tokens.