From ac398c3bafa6e4c80e20571373a96947db863b3d Mon Sep 17 00:00:00 2001 From: Lasse Collin Date: Sun, 13 Mar 2016 20:21:49 +0200 Subject: 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. --- INSTALL | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) (limited to 'INSTALL') 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 -- cgit v1.2.3