aboutsummaryrefslogtreecommitdiff
path: root/INSTALL
diff options
context:
space:
mode:
authorLasse Collin <lasse.collin@tukaani.org>2016-03-13 20:21:49 +0200
committerLasse Collin <lasse.collin@tukaani.org>2016-03-13 20:21:49 +0200
commitac398c3bafa6e4c80e20571373a96947db863b3d (patch)
tree4455bf3c9497d344386d662a67954ffe6d5adc6d /INSTALL
parentUpdate THANKS. (diff)
downloadxz-ac398c3bafa6e4c80e20571373a96947db863b3d.tar.xz
liblzma: Disable external SHA-256 by default.
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.
Diffstat (limited to '')
-rw-r--r--INSTALL36
1 files changed, 36 insertions, 0 deletions
diff --git a/INSTALL b/INSTALL
index 22ef0773..fb2b6d7c 100644
--- a/INSTALL
+++ b/INSTALL
@@ -246,6 +246,42 @@ XZ Utils Installation
the liblzma ABI, so this option should be used only when
it is known to not cause problems.
+ --enable-external-sha256
+ Try to use SHA-256 code from the operating system libc
+ or similar base system libraries. This doesn't try to
+ use OpenSSL or libgcrypt or such libraries.
+
+ The reasons to use this option:
+
+ - It makes liblzma slightly smaller.
+
+ - It might improve SHA-256 speed if the implementation
+ in the operating is very good (but see below).
+
+ External SHA-256 is disabled by default for two reasons:
+
+ - On some operating systems the symbol names of the
+ SHA-256 functions conflict with OpenSSL's libcrypto.
+ This causes weird problems such as decompression
+ errors if an application is linked against both
+ liblzma and libcrypto. This problem affects at least
+ FreeBSD 10 and older and MINIX 3.3.0 and older, but
+ other OSes that provide a function "SHA256_Init" might
+ also be affected. FreeBSD 11 has the problem fixed.
+ NetBSD had the problem but it was fixed it in 2009
+ already. OpenBSD uses "SHA256Init" and thus never had
+ a conflict with libcrypto.
+
+ - The SHA-256 code in liblzma is faster than the SHA-256
+ code provided by some operating systems. If you are
+ curious, build two copies of xz (internal and external
+ SHA-256) and compare the decompression (xz --test)
+ times:
+
+ dd if=/dev/zero bs=1024k count=1024 \
+ | xz -v -0 -Csha256 > foo.xz
+ time xz --test foo.xz
+
--disable-xz
--disable-xzdec
--disable-lzmadec