| blob | 670e398981e38a63958b8feef83a9d09f58912ec |
2 XZ Utils Installation
3 =====================
5 0. Preface
6 1. Supported platforms
7 1.1. Compilers
8 1.2. Platform-specific notes
9 1.2.1. AIX
10 1.2.2. IRIX
11 1.2.3. MINIX 3
12 1.2.4. OpenVMS
13 1.2.5. Solaris, OpenSolaris, and derivatives
14 1.2.6. Tru64
15 1.2.7. Windows
16 1.2.8. DOS
17 1.2.9. z/OS
18 1.3. Adding support for new platforms
19 2. configure options
20 2.1. Static vs. dynamic linking of liblzma
21 2.2. Optimizing xzdec and lzmadec
22 3. xzgrep and other scripts
23 3.1. Dependencies
24 3.2. PATH
25 4. Tests
26 4.1 Testing in parallel
27 4.2 Cross compiling
28 5. Troubleshooting
29 5.1. "No C99 compiler was found."
30 5.2. "No POSIX conforming shell (sh) was found."
31 5.3. configure works but build fails at crc32_x86.S
32 5.4. Lots of warnings about symbol visibility
33 5.5. "make check" fails
34 5.6. liblzma.so (or similar) not found when running xz
37 0. Preface
38 ----------
40 If you aren't familiar with building packages that use GNU Autotools,
41 see the file INSTALL.generic for generic instructions before reading
42 further.
44 If you are going to build a package for distribution, see also the
45 file PACKAGERS. It contains information that should help making the
46 binary packages as good as possible, but the information isn't very
47 interesting to those making local builds for private use or for use
48 in special situations like embedded systems.
51 1. Supported platforms
52 ----------------------
54 XZ Utils are developed on GNU/Linux, but they should work on many
55 POSIX-like operating systems like *BSDs and Solaris, and even on
56 a few non-POSIX operating systems.
59 1.1. Compilers
61 A C99 compiler is required to compile XZ Utils. If you use GCC, you
62 need at least version 3.x.x. GCC version 2.xx.x doesn't support some
63 C99 features used in XZ Utils source code, thus GCC 2 won't compile
64 XZ Utils.
66 XZ Utils takes advantage of some GNU C extensions when building
67 with GCC. Because these extensions are used only when building
68 with GCC, it should be possible to use any C99 compiler.
71 1.2. Platform-specific notes
73 1.2.1. AIX
75 If you use IBM XL C compiler, pass CC=xlc_r to configure. If
76 you use CC=xlc instead, you must disable threading support
77 with --disable-threads (usually not recommended).
80 1.2.2. IRIX
82 MIPSpro 7.4.4m has been reported to produce broken code if using
83 the -O2 optimization flag ("make check" fails). Using -O1 should
84 work.
86 A problem has been reported when using shared liblzma. Passing
87 --disable-shared to configure works around this. Alternatively,
88 putting "-64" to CFLAGS to build a 64-bit version might help too.
91 1.2.3. MINIX 3
93 The default install of MINIX 3 includes Amsterdam Compiler Kit (ACK),
94 which doesn't support C99. Install GCC to compile XZ Utils.
96 MINIX 3.1.8 and older have bugs in /usr/include/stdint.h, which has
97 to be patched before XZ Utils can be compiled correctly. See
98 <http://gforge.cs.vu.nl/gf/project/minix/tracker/?action=TrackerItemEdit&tracker_item_id=537>.
100 MINIX 3.2.0 and later use a different libc and aren't affected by
101 the above bug.
103 XZ Utils doesn't have code to detect the amount of physical RAM and
104 number of CPU cores on MINIX 3.
106 See section 5.4 in this file about symbol visibility warnings (you
107 may want to pass gl_cv_cc_visibility=no to configure).
110 1.2.4. OpenVMS
112 XZ Utils can be built for OpenVMS, but the build system files
113 are not included in the XZ Utils source package. The required
114 OpenVMS-specific files are maintained by Jouk Jansen and can be
115 downloaded here:
117 http://nchrem.tnw.tudelft.nl/openvms/software2.html#xzutils
120 1.2.5. Solaris, OpenSolaris, and derivatives
122 The following linker error has been reported on some x86 systems:
124 ld: fatal: relocation error: R_386_GOTOFF: ...
126 This can be worked around by passing gl_cv_cc_visibility=no
127 as an argument to the configure script.
129 test_scripts.sh in "make check" may fail if good enough tools are
130 missing from PATH (/usr/xpg4/bin or /usr/xpg6/bin). Nowadays
131 /usr/xpg4/bin is added to the script PATH by default on Solaris
132 (see --enable-path-for-scripts=PREFIX in section 2), but old xz
133 releases needed extra steps. See sections 5.5 and 3.2 for more
134 information.
137 1.2.6. Tru64
139 If you try to use the native C compiler on Tru64 (passing CC=cc to
140 configure), you may need the workaround mention in section 5.1 in
141 this file (pass also ac_cv_prog_cc_c99= to configure).
144 1.2.7. Windows
146 If it is enough to build liblzma (no command line tools):
148 - There is CMake support. It should be good enough to build
149 static liblzma or liblzma.dll with Visual Studio. The CMake
150 support may work with MinGW or MinGW-w64. Read the comment
151 in the beginning of CMakeLists.txt before running CMake!
153 - There are Visual Studio project files under the "windows"
154 directory. See windows/INSTALL-MSVC.txt. In the future the
155 project files will be removed when CMake support is good
156 enough. Thus, please test the CMake version and help fix
157 possible issues.
159 To build also the command line tools:
161 - MinGW-w64 + MSYS (32-bit and 64-bit x86): This is used
162 for building the official binary packages for Windows.
163 There is windows/build.bash to ease packaging XZ Utils with
164 MinGW(-w64) + MSYS into a redistributable .zip or .7z file.
165 See windows/INSTALL-MinGW.txt for more information.
167 - MinGW + MSYS (32-bit x86): I haven't recently tested this.
169 - Cygwin 1.7.35 and later: NOTE that using XZ Utils >= 5.2.0
170 under Cygwin older than 1.7.35 can lead to DATA LOSS! If
171 you must use an old Cygwin version, stick to XZ Utils 5.0.x
172 which is safe under older Cygwin versions. You can check
173 the Cygwin version with the command "cygcheck -V".
175 It may be possible to build liblzma with other toolchains too, but
176 that will probably require writing a separate makefile. Building
177 the command line tools with non-GNU toolchains will be harder than
178 building only liblzma.
180 Even if liblzma is built with MinGW(-w64), the resulting DLL can
181 be used by other compilers and linkers, including MSVC. See
182 windows/README-Windows.txt for details.
185 1.2.8. DOS
187 There is a Makefile in the "dos" directory to build XZ Utils on
188 DOS using DJGPP. Support for long file names (LFN) is needed at
189 build time but the resulting xz.exe works without LFN support too.
190 See dos/INSTALL.txt and dos/README.txt for more information.
193 1.2.9. z/OS
195 To build XZ Utils on z/OS UNIX System Services using xlc, pass
196 these options to the configure script: CC='xlc -qhaltonmsg=CCN3296'
197 CPPFLAS='-D_UNIX03_THREADS -D_XOPEN_SOURCE=600'. The first makes
198 xlc throw an error if a header file is missing, which is required
199 to make the tests in configure work. The CPPFLAGS are needed to
200 get pthread support (some other CPPFLAGS may work too; if there
201 are problems, try -D_UNIX95_THREADS instead of -D_UNIX03_THREADS).
203 test_scripts.sh in "make check" will fail even if the scripts
204 actually work because the test data includes compressed files
205 with US-ASCII text.
207 No other tests should fail. If test_files.sh fails, check that
208 the included .xz test files weren't affected by EBCDIC conversion.
210 XZ Utils doesn't have code to detect the amount of physical RAM and
211 number of CPU cores on z/OS.
214 1.3. Adding support for new platforms
216 If you have written patches to make XZ Utils to work on previously
217 unsupported platform, please send the patches to me! I will consider
218 including them to the official version. It's nice to minimize the
219 need of third-party patching.
221 One exception: Don't request or send patches to change the whole
222 source package to C89. I find C99 substantially nicer to write and
223 maintain. However, the public library headers must be in C89 to
224 avoid frustrating those who maintain programs, which are strictly
225 in C89 or C++.
228 2. configure options
229 --------------------
231 In most cases, the defaults are what you want. Many of the options
232 below are useful only when building a size-optimized version of
233 liblzma or command line tools.
235 --enable-encoders=LIST
236 --disable-encoders
237 Specify a comma-separated LIST of filter encoders to
238 build. See "./configure --help" for exact list of
239 available filter encoders. The default is to build all
240 supported encoders.
242 If LIST is empty or --disable-encoders is used, no filter
243 encoders will be built and also the code shared between
244 encoders will be omitted.
246 Disabling encoders will remove some symbols from the
247 liblzma ABI, so this option should be used only when it
248 is known to not cause problems.
250 --enable-decoders=LIST
251 --disable-decoders
252 This is like --enable-encoders but for decoders. The
253 default is to build all supported decoders.
255 --enable-match-finders=LIST
256 liblzma includes two categories of match finders:
257 hash chains and binary trees. Hash chains (hc3 and hc4)
258 are quite fast but they don't provide the best compression
259 ratio. Binary trees (bt2, bt3 and bt4) give excellent
260 compression ratio, but they are slower and need more
261 memory than hash chains.
263 You need to enable at least one match finder to build the
264 LZMA1 or LZMA2 filter encoders. Usually hash chains are
265 used only in the fast mode, while binary trees are used to
266 when the best compression ratio is wanted.
268 The default is to build all the match finders if LZMA1
269 or LZMA2 filter encoders are being built.
271 --enable-checks=LIST
272 liblzma support multiple integrity checks. CRC32 is
273 mandatory, and cannot be omitted. See "./configure --help"
274 for exact list of available integrity check types.
276 liblzma and the command line tools can decompress files
277 which use unsupported integrity check type, but naturally
278 the file integrity cannot be verified in that case.
280 Disabling integrity checks may remove some symbols from
281 the liblzma ABI, so this option should be used only when
282 it is known to not cause problems.
284 --enable-external-sha256
285 Try to use SHA-256 code from the operating system libc
286 or similar base system libraries. This doesn't try to
287 use OpenSSL or libgcrypt or such libraries.
289 The reasons to use this option:
291 - It makes liblzma slightly smaller.
293 - It might improve SHA-256 speed if the implementation
294 in the operating is very good (but see below).
296 External SHA-256 is disabled by default for two reasons:
298 - On some operating systems the symbol names of the
299 SHA-256 functions conflict with OpenSSL's libcrypto.
300 This causes weird problems such as decompression
301 errors if an application is linked against both
302 liblzma and libcrypto. This problem affects at least
303 FreeBSD 10 and older and MINIX 3.3.0 and older, but
304 other OSes that provide a function "SHA256_Init" might
305 also be affected. FreeBSD 11 has the problem fixed.
306 NetBSD had the problem but it was fixed it in 2009
307 already. OpenBSD uses "SHA256Init" and thus never had
308 a conflict with libcrypto.
310 - The SHA-256 code in liblzma is faster than the SHA-256
311 code provided by some operating systems. If you are
312 curious, build two copies of xz (internal and external
313 SHA-256) and compare the decompression (xz --test)
314 times:
316 dd if=/dev/zero bs=1024k count=1024 \
317 | xz -v -0 -Csha256 > foo.xz
318 time xz --test foo.xz
320 --disable-microlzma
321 Don't build MicroLZMA encoder and decoder. This omits
322 lzma_microlzma_encoder() and lzma_microlzma_decoder()
323 API functions from liblzma. These functions are needed
324 by specific applications only. They were written for
325 erofs-utils but they may be used by others too.
327 --disable-lzip-decoder
328 Disable decompression support for .lz (lzip) files.
329 This omits the API function lzma_lzip_decoder() from
330 liblzma and .lz support from the xz tool.
332 --disable-xz
333 --disable-xzdec
334 --disable-lzmadec
335 --disable-lzmainfo
336 Don't build and install the command line tool mentioned
337 in the option name.
339 NOTE: Disabling xz will skip some tests in "make check".
341 NOTE: If xzdec is disabled and lzmadec is left enabled,
342 a dangling man page symlink lzmadec.1 -> xzdec.1 is
343 created.
345 --disable-lzma-links
346 Don't create symlinks for LZMA Utils compatibility.
347 This includes lzma, unlzma, and lzcat. If scripts are
348 installed, also lzdiff, lzcmp, lzgrep, lzegrep, lzfgrep,
349 lzmore, and lzless will be omitted if this option is used.
351 --disable-scripts
352 Don't install the scripts xzdiff, xzgrep, xzmore, xzless,
353 and their symlinks.
355 --disable-doc
356 Don't install the documentation files to $docdir
357 (often /usr/doc/xz or /usr/local/doc/xz). Man pages
358 will still be installed. The $docdir can be changed
359 with --docdir=DIR.
361 --disable-assembler
362 liblzma includes some assembler optimizations. Currently
363 there is only assembler code for CRC32 and CRC64 for
364 32-bit x86.
366 All the assembler code in liblzma is position-independent
367 code, which is suitable for use in shared libraries and
368 position-independent executables. So far only i386
369 instructions are used, but the code is optimized for i686
370 class CPUs. If you are compiling liblzma exclusively for
371 pre-i686 systems, you may want to disable the assembler
372 code.
374 --disable-clmul-crc
375 Disable the use of carryless multiplication for CRC
376 calculation even if compiler support for it is detected.
377 The code uses runtime detection of SSSE3, SSE4.1, and
378 CLMUL instructions on x86. On 32-bit x86 this currently
379 is used only if --disable-assembler is used (this might
380 be fixed in the future). The code works on E2K too.
382 If using compiler options that unconditionally allow the
383 required extensions (-msse4.1 -mpclmul) then runtime
384 detection isn't used and the generic code is omitted.
386 --disable-arm64-crc32
387 Disable the use of the ARM64 CRC32 instruction extension
388 even if compiler support for it is detected. The code will
389 detect support for the instruction at runtime.
391 If using compiler options that unconditionally allow the
392 required extensions (-march=armv8-a+crc or -march=armv8.1-a
393 and later) then runtime detection isn't used and the
394 generic code is omitted.
396 --enable-unaligned-access
397 Allow liblzma to use unaligned memory access for 16-bit,
398 32-bit, and 64-bit loads and stores. This should be
399 enabled only when the hardware supports this, that is,
400 when unaligned access is fast. Some operating system
401 kernels emulate unaligned access, which is extremely
402 slow. This option shouldn't be used on systems that
403 rely on such emulation.
405 Unaligned access is enabled by default on these:
406 - 32-bit x86
407 - 64-bit x86-64
408 - 32-bit big endian PowerPC
409 - 64-bit big endian PowerPC
410 - 64-bit little endian PowerPC
411 - some RISC-V [1]
412 - some 32-bit ARM [2]
413 - some 64-bit ARM64 [2] (NOTE: Autodetection bug
414 if using GCC -mstrict-align, see below.)
416 [1] Unaligned access is enabled by default if
417 configure sees that the C compiler
418 #defines __riscv_misaligned_fast.
420 [2] Unaligned access is enabled by default if
421 configure sees that the C compiler
422 #defines __ARM_FEATURE_UNALIGNED:
424 - ARMv7 + GCC or Clang: It works. The options
425 -munaligned-access and -mno-unaligned-access
426 affect this macro correctly.
428 - ARM64 + Clang: It works. The options
429 -munaligned-access, -mno-unaligned-access,
430 and -mstrict-align affect this macro correctly.
431 Clang >= 17 supports -mno-strict-align too.
433 - ARM64 + GCC: It partially works. The macro
434 is always #defined by GCC versions at least
435 up to 13.2, even when using -mstrict-align.
436 If building for strict-align ARM64, the
437 configure option --disable-unaligned-access
438 should be used if using a GCC version that has
439 this issue because otherwise the performance
440 may be degraded. It likely won't crash due to
441 how unaligned access is done in the C code.
443 --enable-unsafe-type-punning
444 This enables use of code like
446 uint8_t *buf8 = ...;
447 *(uint32_t *)buf8 = ...;
449 which violates strict aliasing rules and may result
450 in broken code. There should be no need to use this
451 option with recent GCC or Clang versions on any
452 arch as just as fast code can be generated in a safe
453 way too (using __builtin_assume_aligned + memcpy).
455 However, this option might improve performance in some
456 other cases, especially with old compilers (for example,
457 GCC 3 and early 4.x on x86, GCC < 6 on ARMv6 and ARMv7).
459 --enable-small
460 Reduce the size of liblzma by selecting smaller but
461 semantically equivalent version of some functions, and
462 omit precomputed lookup tables. This option tends to
463 make liblzma slightly slower.
465 Note that while omitting the precomputed tables makes
466 liblzma smaller on disk, the tables are still needed at
467 run time, and need to be computed at startup. This also
468 means that the RAM holding the tables won't be shared
469 between applications linked against shared liblzma.
471 This option doesn't modify CFLAGS to tell the compiler
472 to optimize for size. You need to add -Os or equivalent
473 flag(s) to CFLAGS manually.
475 --enable-assume-ram=SIZE
476 On the most common operating systems, XZ Utils is able to
477 detect the amount of physical memory on the system. This
478 information is used by the options --memlimit-compress,
479 --memlimit-decompress, and --memlimit when setting the
480 limit to a percentage of total RAM.
482 On some systems, there is no code to detect the amount of
483 RAM though. Using --enable-assume-ram one can set how much
484 memory to assume on these systems. SIZE is given as MiB.
485 The default is 128 MiB.
487 Feel free to send patches to add support for detecting
488 the amount of RAM on the operating system you use. See
489 src/common/tuklib_physmem.c for details.
491 --enable-threads=METHOD
492 Threading support is enabled by default so normally there
493 is no need to specify this option.
495 Supported values for METHOD:
497 yes Autodetect the threading method. If none
498 is found, configure will give an error.
500 posix Use POSIX pthreads. This is the default
501 except on Windows outside Cygwin.
503 win95 Use Windows 95 compatible threads. This
504 is compatible with Windows XP and later
505 too. This is the default for 32-bit x86
506 Windows builds. Unless the compiler
507 supports __attribute__((__constructor__)),
508 the 'win95' threading is incompatible with
509 --enable-small.
511 vista Use Windows Vista compatible threads. The
512 resulting binaries won't run on Windows XP
513 or older. This is the default for Windows
514 excluding 32-bit x86 builds (that is, on
515 x86-64 the default is 'vista').
517 no Disable threading support. This is the
518 same as using --disable-threads.
519 NOTE: If combined with --enable-small
520 and the compiler doesn't support
521 __attribute__((__constructor__)), the
522 resulting liblzma won't be thread safe,
523 that is, if a multi-threaded application
524 calls any liblzma functions from more than
525 one thread, something bad may happen.
527 --enable-ifunc
528 Use __attribute__((__ifunc__())) in liblzma. This is
529 enabled by default on GNU/Linux and FreeBSD.
531 The ifunc attribute is incompatible with
532 -fsanitize=address. --disable-ifunc must be used
533 if any -fsanitize= option is specified in CFLAGS.
535 --enable-sandbox=METHOD
536 There is limited sandboxing support in the xz and xzdec
537 tools. If built with sandbox support, xz uses it
538 automatically when (de)compressing exactly one file to
539 standard output when the options --files or --files0 aren't
540 used. This is a common use case, for example,
541 (de)compressing .tar.xz files via GNU tar. The sandbox is
542 also used for single-file 'xz --test' or 'xz --list'.
543 xzdec always uses the sandbox, except when more than one
544 file are decompressed. In this case it will enable the
545 sandbox for the last file that is decompressed.
547 Supported METHODs:
549 auto Look for a supported sandboxing method
550 and use it if found. If no method is
551 found, then sandboxing isn't used.
552 This is the default.
554 no Disable sandboxing support.
556 capsicum
557 Use Capsicum (FreeBSD >= 10.2) for
558 sandboxing. If no Capsicum support
559 is found, configure will give an error.
561 pledge Use pledge(2) (OpenBSD >= 5.9) for
562 sandboxing. If pledge(2) isn't found,
563 configure will give an error.
565 landlock
566 Use Landlock (Linux >= 5.13) for
567 sandboxing. If no Landlock support
568 is found, configure will give an error.
570 --enable-symbol-versions
571 Use symbol versioning for liblzma. This is enabled by
572 default on GNU/Linux, other GNU-based systems, and
573 FreeBSD.
575 --enable-debug
576 This enables the assert() macro and possibly some other
577 run-time consistency checks. It makes the code slower, so
578 you normally don't want to have this enabled.
580 --enable-werror
581 If building with GCC, make all compiler warnings an error,
582 that abort the compilation. This may help catching bugs,
583 and should work on most systems. This has no effect on the
584 resulting binaries.
586 --enable-path-for-scripts=PREFIX
587 If PREFIX isn't empty, PATH=PREFIX:$PATH will be set in
588 the beginning of the scripts (xzgrep and others).
589 The default is empty except on Solaris the default is
590 /usr/xpg4/bin.
592 This can be useful if the default PATH doesn't contain
593 modern POSIX tools (as can be the case on Solaris) or if
594 one wants to ensure that the correct xz binary is in the
595 PATH for the scripts. Note that the latter use can break
596 "make check" if the prefixed PATH causes a wrong xz binary
597 (other than the one that was just built) to be used.
599 Older xz releases support a different method for setting
600 the PATH for the scripts. It is described in section 3.2
601 and is supported in this xz version too.
604 2.1. Static vs. dynamic linking of liblzma
606 On 32-bit x86, linking against static liblzma can give a minor
607 speed improvement. Static libraries on x86 are usually compiled as
608 position-dependent code (non-PIC) and shared libraries are built as
609 position-independent code (PIC). PIC wastes one register, which can
610 make the code slightly slower compared to a non-PIC version. (Note
611 that this doesn't apply to x86-64.)
613 If you want to link xz against static liblzma, the simplest way
614 is to pass --disable-shared to configure. If you want also shared
615 liblzma, run configure again and run "make install" only for
616 src/liblzma.
619 2.2. Optimizing xzdec and lzmadec
621 xzdec and lzmadec are intended to be relatively small instead of
622 optimizing for the best speed. Thus, it is a good idea to build
623 xzdec and lzmadec separately:
625 - To link the tools against static liblzma, pass --disable-shared
626 to configure.
628 - To select somewhat size-optimized variant of some things in
629 liblzma, pass --enable-small to configure.
631 - Tell the compiler to optimize for size instead of speed.
632 For example, with GCC, put -Os into CFLAGS.
634 - xzdec and lzmadec will never use multithreading capabilities of
635 liblzma. You can avoid dependency on libpthread by passing
636 --disable-threads to configure.
638 - There are and will be no translated messages for xzdec and
639 lzmadec, so it is fine to pass also --disable-nls to configure.
641 - Only decoder code is needed, so you can speed up the build
642 slightly by passing --disable-encoders to configure. This
643 shouldn't affect the final size of the executables though,
644 because the linker is able to omit the encoder code anyway.
646 If you have no use for xzdec or lzmadec, you can disable them with
647 --disable-xzdec and --disable-lzmadec.
650 3. xzgrep and other scripts
651 ---------------------------
653 3.1. Dependencies
655 POSIX shell (sh) and bunch of other standard POSIX tools are required
656 to run the scripts. The configure script tries to find a POSIX
657 compliant sh, but if it fails, you can force the shell by passing
658 gl_cv_posix_shell=/path/to/posix-sh as an argument to the configure
659 script.
661 xzdiff (xzcmp/lzdiff/lzcmp) may use mktemp if it is available. As
662 a fallback xzdiff will use mkdir to securely create a temporary
663 directory. Having mktemp available is still recommended since the
664 mkdir fallback method isn't as robust as mktemp is. The original
665 mktemp can be found from <https://www.mktemp.org/>. On GNU, most will
666 use the mktemp program from GNU coreutils instead of the original
667 implementation. Both mktemp versions are fine.
669 In addition to using xz to decompress .xz files, xzgrep and xzdiff
670 use gzip, bzip2, and lzop to support .gz, bz2, and .lzo files.
673 3.2. PATH
675 The method described below is supported by older xz releases.
676 It is supported by the current version too, but the newer
677 --enable-path-for-scripts=PREFIX described in section 2 may be
678 more convenient.
680 The scripts assume that the required tools (standard POSIX utilities,
681 mktemp, and xz) are in PATH; the scripts don't set the PATH themselves
682 (except as described for --enable-path-for-scripts=PREFIX). Some
683 people like this while some think this is a bug. Those in the latter
684 group can easily patch the scripts before running the configure script
685 by taking advantage of a placeholder line in the scripts.
687 For example, to make the scripts prefix /usr/bin:/bin to PATH:
689 perl -pi -e 's|^#SET_PATH.*$|PATH=/usr/bin:/bin:\$PATH|' \
690 src/scripts/xz*.in
693 4. Tests
694 --------
696 The test framework can be built and run by executing "make check" in
697 the build directory. The tests are a mix of executables and POSIX
698 shell scripts (sh). All tests should pass if the default configuration
699 is used. Disabling features through the configure options may cause
700 some tests to be skipped. If any tests do not pass, see section 5.5.
703 4.1. Testing in parallel
705 The tests can be run in parallel using the "-j" make option on systems
706 that support it. For instance, "make -j4 check" will run up to four
707 tests simultaneously.
710 4.2. Cross compiling
712 The tests can be built without running them:
714 make check TESTS=
716 The TESTS variable is the list of tests you wish to run. Leaving it
717 empty will compile the tests without running any.
719 If the tests are copied to a target machine to execute, the test data
720 files in the directory tests/files must also be copied. The tests
721 search for the data files using the environment variable $srcdir,
722 expecting to find the data files under $srcdir/files/. If $srcdir
723 isn't set then it defaults to the current directory.
725 The shell script tests can be copied from the source directory to the
726 target machine to execute. In addition to the test files, these tests
727 will expect the following relative file paths to execute properly:
729 ./create_compress_files
730 ../config.h
731 ../src/xz/xz
732 ../src/xzdec/xzdec
733 ../src/scripts/xzdiff
734 ../src/scripts/xzgrep
737 5. Troubleshooting
738 ------------------
740 5.1. "No C99 compiler was found."
742 You need a C99 compiler to build XZ Utils. If the configure script
743 cannot find a C99 compiler and you think you have such a compiler
744 installed, set the compiler command by passing CC=/path/to/c99 as
745 an argument to the configure script.
747 If you get this error even when you think your compiler supports C99,
748 you can override the test by passing ac_cv_prog_cc_c99= as an argument
749 to the configure script. The test for C99 compiler is not perfect (and
750 it is not as easy to make it perfect as it sounds), so sometimes this
751 may be needed. You will get a compile error if your compiler doesn't
752 support enough C99.
755 5.2. "No POSIX conforming shell (sh) was found."
757 xzgrep and other scripts need a shell that (roughly) conforms
758 to POSIX. The configure script tries to find such a shell. If
759 it fails, you can force the shell to be used by passing
760 gl_cv_posix_shell=/path/to/posix-sh as an argument to the configure
761 script. Alternatively you can omit the installation of scripts and
762 this error by passing --disable-scripts to configure.
765 5.3. configure works but build fails at crc32_x86.S
767 The easy fix is to pass --disable-assembler to the configure script.
769 The configure script determines if assembler code can be used by
770 looking at the configure triplet; there is currently no check if
771 the assembler code can actually actually be built. The x86 assembler
772 code should work on x86 GNU/Linux, *BSDs, Solaris, Darwin, MinGW,
773 Cygwin, and DJGPP. On other x86 systems, there may be problems and
774 the assembler code may need to be disabled with the configure option.
776 If you get this error when building for x86-64, you have specified or
777 the configure script has misguessed your architecture. Pass the
778 correct configure triplet using the --build=CPU-COMPANY-SYSTEM option
779 (see INSTALL.generic).
782 5.4. Lots of warnings about symbol visibility
784 On some systems where symbol visibility isn't supported, GCC may
785 still accept the visibility options and attributes, which will make
786 configure think that visibility is supported. This will result in
787 many compiler warnings. You can avoid the warnings by forcing the
788 visibility support off by passing gl_cv_cc_visibility=no as an
789 argument to the configure script. This has no effect on the
790 resulting binaries, but fewer warnings looks nicer and may allow
791 using --enable-werror.
794 5.5. "make check" fails
796 If the other tests pass but test_scripts.sh fails, then the problem
797 is in the scripts in src/scripts. Comparing the contents of
798 tests/xzgrep_test_output to tests/xzgrep_expected_output might
799 give a good idea about problems in xzgrep. One possibility is that
800 some tools are missing from the current PATH or the tools lack
801 support for some POSIX features. This can happen at least on
802 Solaris where the tools in /bin may be ancient but good enough
803 tools are available in /usr/xpg4/bin or /usr/xpg6/bin. For possible
804 fixes, see --enable-path-for-scripts=PREFIX in section 2 and the
805 older alternative method described in section 3.2 of this file.
807 If tests other than test_scripts.sh fail, a likely reason is that
808 libtool links the test programs against an installed version of
809 liblzma instead of the version that was just built. This is
810 obviously a bug which seems to happen on some platforms.
811 A workaround is to uninstall the old liblzma versions first.
813 If the problem isn't any of those described above, then it's likely
814 a bug in XZ Utils or in the compiler. See the platform-specific
815 notes in this file for possible known problems. Please report
816 a bug if you cannot solve the problem. See README for contact
817 information.
820 5.6. liblzma.so (or similar) not found when running xz
822 If you installed the package with "make install" and get an error
823 about liblzma.so (or a similarly named file) being missing, try
824 running "ldconfig" to update the run-time linker cache (if your
825 operating system has such a command).