The latest stable is 3.3.0 and it's from 2014.
Don't mention the older versions in INSTALL.
3.3.0 ships with Clang already.
Testing with 3.4.0beta6 shows that tuklib_physmem
works too so omit comments about that from INSTALL.
Visibility warnigns weren't a problem either.
Thus it's enough to mention the need for --disable-threads
as configure doesn't autodetect the lack of pthreads.
(cherry picked from commit 50e1948938)
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 689ae24273)
PowerPC64LE wasn't tested but it seems like a safe change.
POWER8 supports unaligned access in little endian mode. Testing
on godbolt.org shows that GCC uses unaligned access by default.
The RISC-V macro __riscv_misaligned_fast is very new and not
in any stable compiler release yet.
Documentation in INSTALL was updated to match.
Documentation about an autodetection bug when using ARM64 GCC
with -mstrict-align was added to INSTALL.
CMake files weren't updated yet.
The new Tests section describes basic information about the tests, how
to run them, and important details when cross compiling. We have had a
few questions about how to compile the tests without running them, so
hopefully this information will help others with the same question in the
future.
Fixes: https://github.com/tukaani-project/xz/issues/54
Using CMake to build liblzma should work on a few other OSes
but building the command line tools is still subtly broken.
It is known that shared library versioning may differ between
CMake and Libtool builds on some OSes, most notably Darwin.
It also works on E2K as it supports these intrinsics.
On x86-64 runtime detection is used so the code keeps working on
older processors too. A CLMUL-only build can be done by using
-msse4.1 -mpclmul in CFLAGS and this will reduce the library
size since the generic implementation and its 8 KiB lookup table
will be omitted.
On 32-bit x86 this isn't used by default for now because by default
on 32-bit x86 the separate assembly file crc64_x86.S is used.
If --disable-assembler is used then this new CLMUL code is used
the same way as on 64-bit x86. However, a CLMUL-only build
(-msse4.1 -mpclmul) won't omit the 8 KiB lookup table on
32-bit x86 due to a currently-missing check for disabled
assembler usage.
The configure.ac check should be such that the code won't be
built if something in the toolchain doesn't support it but
--disable-clmul-crc option can be used to unconditionally
disable this feature.
CLMUL speeds up decompression of files that have compressed very
well (assuming CRC64 is used as a check type). It is know that
the CLMUL code is significantly slower than the generic code for
tiny inputs (especially 1-8 bytes but up to 16 bytes). If that
is a real-world problem then there is already a commented-out
variant that uses the generic version for small inputs.
Thanks to Ilya Kurdyukov for the original patch which was
derived from a white paper from Intel [1] (published in 2009)
and public domain code from [2] (released in 2016).
[1] https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/fast-crc-computation-generic-polynomials-pclmulqdq-paper.pdf
[2] https://github.com/rawrunprotected/crc
This uses it for CRC table initializations when using --disable-small.
It avoids mythread_once() overhead. It also means that then
--disable-small --disable-threads is thread-safe if this attribute
is supported.
This adds a configure option --enable-path-for-scripts=PREFIX
which defaults to empty except on Solaris it is /usr/xpg4/bin
to make POSIX grep and others available. The Solaris case had
been documented in INSTALL with a manual fix but it's better
to do this automatically since it is needed on most Solaris
systems anyway.
Thanks to Daniel Richard G.
This is the sane thing to do. The conflict with OpenSSL
on some OSes and especially that the OS-provided versions
can be significantly slower makes it clear that it was
a mistake to have the external SHA-256 support enabled by
default.
Those who want it can now pass --enable-external-sha256 to
configure. INSTALL was updated with notes about OSes where
this can be a bad idea.
The SHA-256 detection code in configure.ac had some bugs that
could lead to a build failure in some situations. These were
fixed, although it doesn't matter that much now that the
external SHA-256 is disabled by default.
MINIX >= 3.2.0 uses NetBSD's libc and thus has SHA256_Init
in libc instead of libutil. Support for the libutil version
was removed.
Mention the possible "make check" failure on Solaris in the
Solaris-specific section of INSTALL. It was already in
section 4.5 but it is better mention it in the OS-specific
section too.
Add a note about failing "make check". The source of
the problem should be fixed in libtool (if it really is
a libtool bug and not mine) but I'm unable to spend time
on that for now. Thanks to Nelson H. F. Beebe for reporting
the issue.
Add a note about a possible need to run "ldconfig" after
"make install".
Now liblzma only uses "mythread" functions and types
which are defined in mythread.h matching the desired
threading method.
Before Windows Vista, there is no direct equivalent to
pthread condition variables. Since this package doesn't
use pthread_cond_broadcast(), pre-Vista threading can
still be kept quite simple. The pre-Vista code doesn't
use anything that wasn't already available in Windows 95,
so the binaries should run even on Windows 95 if someone
happens to care.
RainRat
Lasse Collin
Jia Tan