8 1.2. Platform-specific notes
13 1.2.5. Solaris, OpenSolaris, and derivatives
18 1.3. Adding support for new platforms
20 2.1. Static vs. dynamic linking of liblzma
21 2.2. Optimizing xzdec and lzmadec
22 3. xzgrep and other scripts
26 4.1 Testing in parallel
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
40 If you aren't familiar with building packages that use GNU Autotools,
41 see the file INSTALL.generic for generic instructions before reading
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.
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
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
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).
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
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.
93 Version 3.3.0 and later are supported.
95 Multithreading isn't supported because MINIX 3 doesn't have
96 pthreads. The option --disable-threads must be passed to configure
97 as this isn't autodetected.
99 Note that disabling threads causes "make check" to show a few tests
100 as skipped ("SKIP"). It's only due to a few threading-dependent
101 subtests are skipped. See the matching tests/test_*.log files.
106 XZ Utils can be built for OpenVMS, but the build system files
107 are not included in the XZ Utils source package. The required
108 OpenVMS-specific files are maintained by Jouk Jansen and can be
111 http://nchrem.tnw.tudelft.nl/openvms/software2.html#xzutils
114 1.2.5. Solaris, OpenSolaris, and derivatives
116 The following linker error has been reported on some x86 systems:
118 ld: fatal: relocation error: R_386_GOTOFF: ...
120 This can be worked around by passing gl_cv_cc_visibility=no
121 as an argument to the configure script.
123 test_scripts.sh in "make check" may fail if good enough tools are
124 missing from PATH (/usr/xpg4/bin or /usr/xpg6/bin). Nowadays
125 /usr/xpg4/bin is added to the script PATH by default on Solaris
126 (see --enable-path-for-scripts=PREFIX in section 2), but old xz
127 releases needed extra steps. See sections 5.5 and 3.2 for more
133 If you try to use the native C compiler on Tru64 (passing CC=cc to
134 configure), you may need the workaround mention in section 5.1 in
135 this file (pass also ac_cv_prog_cc_c99= to configure).
140 The "windows" directory contains instructions for a few types
143 - INSTALL-MinGW-w64_with_CMake.txt
144 Simple instructions how to build XZ Utils natively on
145 Windows using only CMake and a prebuilt toolchain
146 (GCC + MinGW-w64 or Clang/LLVM + MinGW-w64).
148 - INSTALL-MinGW-w64_with_Autotools.txt
149 Native build under MSYS2 or cross-compilation from
150 GNU/Linux using a bash script that creates a .zip
151 and .7z archives of the binaries and documentation.
152 The related file README-Windows.txt is for the
153 resulting binary package.
156 Building with MSVC / Visual Studio and CMake.
158 - liblzma-crt-mixing.txt
159 Documentation what to take into account as a programmer
160 if liblzma.dll and the application don't use the same
161 CRT (MSVCRT or UCRT).
165 - Cygwin: https://cygwin.com/
166 Building on Cygwin can be done like on many POSIX operating
167 systems. XZ Utils >= 5.2.0 isn't compatible with Cygwin older
168 than 1.7.35 (data loss!). 1.7.35 was released on 2015-03-04.
170 - MSYS2: https://www.msys2.org/
175 There is a Makefile in the "dos" directory to build XZ Utils on
176 DOS using DJGPP. Support for long file names (LFN) is needed at
177 build time but the resulting xz.exe works without LFN support too.
178 See dos/INSTALL.txt and dos/README.txt for more information.
183 To build XZ Utils on z/OS UNIX System Services using xlc, pass
184 these options to the configure script: CC='xlc -qhaltonmsg=CCN3296'
185 CPPFLAS='-D_UNIX03_THREADS -D_XOPEN_SOURCE=600'. The first makes
186 xlc throw an error if a header file is missing, which is required
187 to make the tests in configure work. The CPPFLAGS are needed to
188 get pthread support (some other CPPFLAGS may work too; if there
189 are problems, try -D_UNIX95_THREADS instead of -D_UNIX03_THREADS).
191 test_scripts.sh in "make check" will fail even if the scripts
192 actually work because the test data includes compressed files
195 No other tests should fail. If test_files.sh fails, check that
196 the included .xz test files weren't affected by EBCDIC conversion.
198 XZ Utils doesn't have code to detect the amount of physical RAM and
199 number of CPU cores on z/OS.
202 1.3. Adding support for new platforms
204 If you have written patches to make XZ Utils to work on previously
205 unsupported platform, please send the patches to me! I will consider
206 including them to the official version. It's nice to minimize the
207 need of third-party patching.
209 One exception: Don't request or send patches to change the whole
210 source package to C89. I find C99 substantially nicer to write and
211 maintain. However, the public library headers must be in C89 to
212 avoid frustrating those who maintain programs, which are strictly
219 In most cases, the defaults are what you want. Many of the options
220 below are useful only when building a size-optimized version of
221 liblzma or command line tools.
223 --enable-encoders=LIST
225 Specify a comma-separated LIST of filter encoders to
226 build. See "./configure --help" for exact list of
227 available filter encoders. The default is to build all
230 If LIST is empty or --disable-encoders is used, no filter
231 encoders will be built and also the code shared between
232 encoders will be omitted.
234 Disabling encoders will remove some symbols from the
235 liblzma ABI, so this option should be used only when it
236 is known to not cause problems.
238 --enable-decoders=LIST
240 This is like --enable-encoders but for decoders. The
241 default is to build all supported decoders.
243 --enable-match-finders=LIST
244 liblzma includes two categories of match finders:
245 hash chains and binary trees. Hash chains (hc3 and hc4)
246 are quite fast but they don't provide the best compression
247 ratio. Binary trees (bt2, bt3 and bt4) give excellent
248 compression ratio, but they are slower and need more
249 memory than hash chains.
251 You need to enable at least one match finder to build the
252 LZMA1 or LZMA2 filter encoders. Usually hash chains are
253 used only in the fast mode, while binary trees are used to
254 when the best compression ratio is wanted.
256 The default is to build all the match finders if LZMA1
257 or LZMA2 filter encoders are being built.
260 liblzma support multiple integrity checks. CRC32 is
261 mandatory, and cannot be omitted. See "./configure --help"
262 for exact list of available integrity check types.
264 liblzma and the command line tools can decompress files
265 which use unsupported integrity check type, but naturally
266 the file integrity cannot be verified in that case.
268 Disabling integrity checks may remove some symbols from
269 the liblzma ABI, so this option should be used only when
270 it is known to not cause problems.
272 --enable-external-sha256
273 Try to use SHA-256 code from the operating system libc
274 or similar base system libraries. This doesn't try to
275 use OpenSSL or libgcrypt or such libraries.
277 The reasons to use this option:
279 - It makes liblzma slightly smaller.
281 - It might improve SHA-256 speed if the implementation
282 in the operating is very good (but see below).
284 External SHA-256 is disabled by default for two reasons:
286 - On some operating systems the symbol names of the
287 SHA-256 functions conflict with OpenSSL's libcrypto.
288 This causes weird problems such as decompression
289 errors if an application is linked against both
290 liblzma and libcrypto. This problem affects at least
291 FreeBSD 10 and older and MINIX 3.3.0 and older, but
292 other OSes that provide a function "SHA256_Init" might
293 also be affected. FreeBSD 11 has the problem fixed.
294 NetBSD had the problem but it was fixed it in 2009
295 already. OpenBSD uses "SHA256Init" and thus never had
296 a conflict with libcrypto.
298 - The SHA-256 code in liblzma is faster than the SHA-256
299 code provided by some operating systems. If you are
300 curious, build two copies of xz (internal and external
301 SHA-256) and compare the decompression (xz --test)
304 dd if=/dev/zero bs=1024k count=1024 \
305 | xz -v -0 -Csha256 > foo.xz
306 time xz --test foo.xz
309 Don't build MicroLZMA encoder and decoder. This omits
310 lzma_microlzma_encoder() and lzma_microlzma_decoder()
311 API functions from liblzma. These functions are needed
312 by specific applications only. They were written for
313 erofs-utils but they may be used by others too.
315 --disable-lzip-decoder
316 Disable decompression support for .lz (lzip) files.
317 This omits the API function lzma_lzip_decoder() from
318 liblzma and .lz support from the xz tool.
324 Don't build and install the command line tool mentioned
327 NOTE: Disabling xz will skip some tests in "make check".
329 NOTE: If xzdec is disabled and lzmadec is left enabled,
330 a dangling man page symlink lzmadec.1 -> xzdec.1 is
334 Don't create symlinks for LZMA Utils compatibility.
335 This includes lzma, unlzma, and lzcat. If scripts are
336 installed, also lzdiff, lzcmp, lzgrep, lzegrep, lzfgrep,
337 lzmore, and lzless will be omitted if this option is used.
340 Don't install the scripts xzdiff, xzgrep, xzmore, xzless,
344 Don't install the documentation files to $docdir
345 (often /usr/doc/xz or /usr/local/doc/xz). Man pages
346 will still be installed. The $docdir can be changed
350 Enable generation of the HTML version of the liblzma API
351 documentation using Doxygen. The resulting files are
352 installed to $docdir/api. This option assumes that
353 the 'doxygen' tool is available.
356 This disables CRC32 and CRC64 assembly code on
357 32-bit x86. This option currently does nothing
358 on other architectures (not even on x86-64).
360 The 32-bit x86 assembly is position-independent code
361 which is suitable for use in shared libraries and
362 position-independent executables. It uses only i386
363 instructions but the code is optimized for i686 class
364 CPUs. If you are compiling liblzma exclusively for
365 pre-i686 systems, you may want to disable the assembler
369 Disable the use of carryless multiplication for CRC
370 calculation even if compiler support for it is detected.
371 The code uses runtime detection of SSSE3, SSE4.1, and
372 CLMUL instructions on x86. On 32-bit x86 this currently
373 is used only if --disable-assembler is used (this might
374 be fixed in the future). The code works on E2K too.
376 If using compiler options that unconditionally allow the
377 required extensions (-msse4.1 -mpclmul) then runtime
378 detection isn't used and the generic code is omitted.
380 --disable-arm64-crc32
381 Disable the use of the ARM64 CRC32 instruction extension
382 even if compiler support for it is detected. The code will
383 detect support for the instruction at runtime.
385 If using compiler options that unconditionally allow the
386 required extensions (-march=armv8-a+crc or -march=armv8.1-a
387 and later) then runtime detection isn't used and the
388 generic code is omitted.
390 --enable-unaligned-access
391 Allow liblzma to use unaligned memory access for 16-bit,
392 32-bit, and 64-bit loads and stores. This should be
393 enabled only when the hardware supports this, that is,
394 when unaligned access is fast. Some operating system
395 kernels emulate unaligned access, which is extremely
396 slow. This option shouldn't be used on systems that
397 rely on such emulation.
399 Unaligned access is enabled by default on these:
402 - 32-bit big endian PowerPC
403 - 64-bit big endian PowerPC
404 - 64-bit little endian PowerPC
406 - some 32-bit ARM [2]
407 - some 64-bit ARM64 [2] (NOTE: Autodetection bug
408 if using GCC -mstrict-align, see below.)
410 [1] Unaligned access is enabled by default if
411 configure sees that the C compiler
412 #defines __riscv_misaligned_fast.
414 [2] Unaligned access is enabled by default if
415 configure sees that the C compiler
416 #defines __ARM_FEATURE_UNALIGNED:
418 - ARMv7 + GCC or Clang: It works. The options
419 -munaligned-access and -mno-unaligned-access
420 affect this macro correctly.
422 - ARM64 + Clang: It works. The options
423 -munaligned-access, -mno-unaligned-access,
424 and -mstrict-align affect this macro correctly.
425 Clang >= 17 supports -mno-strict-align too.
427 - ARM64 + GCC: It partially works. The macro
428 is always #defined by GCC versions at least
429 up to 13.2, even when using -mstrict-align.
430 If building for strict-align ARM64, the
431 configure option --disable-unaligned-access
432 should be used if using a GCC version that has
433 this issue because otherwise the performance
434 may be degraded. It likely won't crash due to
435 how unaligned access is done in the C code.
437 --enable-unsafe-type-punning
438 This enables use of code like
441 *(uint32_t *)buf8 = ...;
443 which violates strict aliasing rules and may result
444 in broken code. There should be no need to use this
445 option with recent GCC or Clang versions on any
446 arch as just as fast code can be generated in a safe
447 way too (using __builtin_assume_aligned + memcpy).
449 However, this option might improve performance in some
450 other cases, especially with old compilers (for example,
451 GCC 3 and early 4.x on x86, GCC < 6 on ARMv6 and ARMv7).
454 Reduce the size of liblzma by selecting smaller but
455 semantically equivalent version of some functions, and
456 omit precomputed lookup tables. This option tends to
457 make liblzma slightly slower.
459 Note that while omitting the precomputed tables makes
460 liblzma smaller on disk, the tables are still needed at
461 run time, and need to be computed at startup. This also
462 means that the RAM holding the tables won't be shared
463 between applications linked against shared liblzma.
465 This option doesn't modify CFLAGS to tell the compiler
466 to optimize for size. You need to add -Os or equivalent
467 flag(s) to CFLAGS manually.
469 --enable-assume-ram=SIZE
470 On the most common operating systems, XZ Utils is able to
471 detect the amount of physical memory on the system. This
472 information is used by the options --memlimit-compress,
473 --memlimit-decompress, and --memlimit when setting the
474 limit to a percentage of total RAM.
476 On some systems, there is no code to detect the amount of
477 RAM though. Using --enable-assume-ram one can set how much
478 memory to assume on these systems. SIZE is given as MiB.
479 The default is 128 MiB.
481 Feel free to send patches to add support for detecting
482 the amount of RAM on the operating system you use. See
483 src/common/tuklib_physmem.c for details.
485 --enable-threads=METHOD
486 Threading support is enabled by default so normally there
487 is no need to specify this option.
489 Supported values for METHOD:
491 yes Autodetect the threading method. If none
492 is found, configure will give an error.
494 posix Use POSIX pthreads. This is the default
495 except on Windows outside Cygwin.
497 win95 Use Windows 95 compatible threads. This
498 is compatible with Windows XP and later
499 too. This is the default for 32-bit x86
500 Windows builds. Unless the compiler
501 supports __attribute__((__constructor__)),
502 the 'win95' threading is incompatible with
505 vista Use Windows Vista compatible threads. The
506 resulting binaries won't run on Windows XP
507 or older. This is the default for Windows
508 excluding 32-bit x86 builds (that is, on
509 x86-64 the default is 'vista').
511 no Disable threading support. This is the
512 same as using --disable-threads.
513 NOTE: If combined with --enable-small
514 and the compiler doesn't support
515 __attribute__((__constructor__)), the
516 resulting liblzma won't be thread safe,
517 that is, if a multi-threaded application
518 calls any liblzma functions from more than
519 one thread, something bad may happen.
521 --enable-sandbox=METHOD
522 There is limited sandboxing support in the xz and xzdec
523 tools. If built with sandbox support, xz uses it
524 automatically when (de)compressing exactly one file to
525 standard output when the options --files or --files0 aren't
526 used. This is a common use case, for example,
527 (de)compressing .tar.xz files via GNU tar. The sandbox is
528 also used for single-file 'xz --test' or 'xz --list'.
529 xzdec always uses the sandbox, except when more than one
530 file are decompressed. In this case it will enable the
531 sandbox for the last file that is decompressed.
535 auto Look for a supported sandboxing method
536 and use it if found. If no method is
537 found, then sandboxing isn't used.
540 no Disable sandboxing support.
543 Use Capsicum (FreeBSD >= 10.2) for
544 sandboxing. If no Capsicum support
545 is found, configure will give an error.
547 pledge Use pledge(2) (OpenBSD >= 5.9) for
548 sandboxing. If pledge(2) isn't found,
549 configure will give an error.
552 Use Landlock (Linux >= 5.13) for
553 sandboxing. If no Landlock support
554 is found, configure will give an error.
556 --enable-symbol-versions[=VARIANT]
557 Use symbol versioning for liblzma shared library.
558 This is enabled by default on GNU/Linux (glibc only),
559 other GNU-based systems, and FreeBSD.
561 Symbol versioning is never used for static liblzma. This
562 option is ignored when not building a shared library.
566 no Disable symbol versioning. This is the
567 same as using --disable-symbol-versions.
569 auto Autodetect between "no", "linux",
572 yes Autodetect between "linux" and
573 "generic". This forces symbol
574 versioning to be used when
575 building a shared library.
577 generic Generic version is the default for
578 FreeBSD and GNU/Linux on MicroBlaze.
580 This is also used on GNU/Linux when
581 building with NVIDIA HPC Compiler
582 because the compiler doesn't support
583 the features required for the "linux"
586 linux Special version for GNU/Linux (glibc
587 only). This adds a few extra symbol
588 versions for compatibility with binaries
589 that have been linked against a liblzma
590 version that has been patched with
591 "xz-5.2.2-compat-libs.patch" from
592 RHEL/CentOS 7. That patch was used
593 by some build tools outside of
597 This enables the assert() macro and possibly some other
598 run-time consistency checks. It makes the code slower, so
599 you normally don't want to have this enabled.
602 If building with GCC, make all compiler warnings an error,
603 that abort the compilation. This may help catching bugs,
604 and should work on most systems. This has no effect on the
607 --enable-path-for-scripts=PREFIX
608 If PREFIX isn't empty, PATH=PREFIX:$PATH will be set in
609 the beginning of the scripts (xzgrep and others).
610 The default is empty except on Solaris the default is
613 This can be useful if the default PATH doesn't contain
614 modern POSIX tools (as can be the case on Solaris) or if
615 one wants to ensure that the correct xz binary is in the
616 PATH for the scripts. Note that the latter use can break
617 "make check" if the prefixed PATH causes a wrong xz binary
618 (other than the one that was just built) to be used.
620 Older xz releases support a different method for setting
621 the PATH for the scripts. It is described in section 3.2
622 and is supported in this xz version too.
625 2.1. Static vs. dynamic linking of liblzma
627 On 32-bit x86, linking against static liblzma can give a minor
628 speed improvement. Static libraries on x86 are usually compiled as
629 position-dependent code (non-PIC) and shared libraries are built as
630 position-independent code (PIC). PIC wastes one register, which can
631 make the code slightly slower compared to a non-PIC version. (Note
632 that this doesn't apply to x86-64.)
634 If you want to link xz against static liblzma, the simplest way
635 is to pass --disable-shared to configure. If you want also shared
636 liblzma, run configure again and run "make install" only for
640 2.2. Optimizing xzdec and lzmadec
642 xzdec and lzmadec are intended to be relatively small instead of
643 optimizing for the best speed. Thus, it is a good idea to build
644 xzdec and lzmadec separately:
646 - To link the tools against static liblzma, pass --disable-shared
649 - To select somewhat size-optimized variant of some things in
650 liblzma, pass --enable-small to configure.
652 - Tell the compiler to optimize for size instead of speed.
653 For example, with GCC, put -Os into CFLAGS.
655 - xzdec and lzmadec will never use multithreading capabilities of
656 liblzma. You can avoid dependency on libpthread by passing
657 --disable-threads to configure.
659 - There are and will be no translated messages for xzdec and
660 lzmadec, so it is fine to pass also --disable-nls to configure.
662 - Only decoder code is needed, so you can speed up the build
663 slightly by passing --disable-encoders to configure. This
664 shouldn't affect the final size of the executables though,
665 because the linker is able to omit the encoder code anyway.
667 If you have no use for xzdec or lzmadec, you can disable them with
668 --disable-xzdec and --disable-lzmadec.
671 3. xzgrep and other scripts
672 ---------------------------
676 POSIX shell (sh) and bunch of other standard POSIX tools are required
677 to run the scripts. The configure script tries to find a POSIX
678 compliant sh, but if it fails, you can force the shell by passing
679 gl_cv_posix_shell=/path/to/posix-sh as an argument to the configure
682 xzdiff (xzcmp/lzdiff/lzcmp) may use mktemp if it is available. As
683 a fallback xzdiff will use mkdir to securely create a temporary
684 directory. Having mktemp available is still recommended since the
685 mkdir fallback method isn't as robust as mktemp is. The original
686 mktemp can be found from <https://www.mktemp.org/>. On GNU, most will
687 use the mktemp program from GNU coreutils instead of the original
688 implementation. Both mktemp versions are fine.
690 In addition to using xz to decompress .xz files, xzgrep and xzdiff
691 use gzip, bzip2, and lzop to support .gz, bz2, and .lzo files.
696 The method described below is supported by older xz releases.
697 It is supported by the current version too, but the newer
698 --enable-path-for-scripts=PREFIX described in section 2 may be
701 The scripts assume that the required tools (standard POSIX utilities,
702 mktemp, and xz) are in PATH; the scripts don't set the PATH themselves
703 (except as described for --enable-path-for-scripts=PREFIX). Some
704 people like this while some think this is a bug. Those in the latter
705 group can easily patch the scripts before running the configure script
706 by taking advantage of a placeholder line in the scripts.
708 For example, to make the scripts prefix /usr/bin:/bin to PATH:
710 perl -pi -e 's|^#SET_PATH.*$|PATH=/usr/bin:/bin:\$PATH|' \
717 The test framework can be built and run by executing "make check" in
718 the build directory. The tests are a mix of executables and POSIX
719 shell scripts (sh). All tests should pass if the default configuration
720 is used. Disabling features through the configure options may cause
721 some tests to be skipped. If any tests do not pass, see section 5.5.
724 4.1. Testing in parallel
726 The tests can be run in parallel using the "-j" make option on systems
727 that support it. For instance, "make -j4 check" will run up to four
728 tests simultaneously.
733 The tests can be built without running them:
737 The TESTS variable is the list of tests you wish to run. Leaving it
738 empty will compile the tests without running any.
740 If the tests are copied to a target machine to execute, the test data
741 files in the directory tests/files must also be copied. The tests
742 search for the data files using the environment variable $srcdir,
743 expecting to find the data files under $srcdir/files/. If $srcdir
744 isn't set then it defaults to the current directory.
746 The shell script tests can be copied from the source directory to the
747 target machine to execute. In addition to the test files, these tests
748 will expect the following relative file paths to execute properly:
750 ./create_compress_files
754 ../src/scripts/xzdiff
755 ../src/scripts/xzgrep
761 5.1. "No C99 compiler was found."
763 You need a C99 compiler to build XZ Utils. If the configure script
764 cannot find a C99 compiler and you think you have such a compiler
765 installed, set the compiler command by passing CC=/path/to/c99 as
766 an argument to the configure script.
768 If you get this error even when you think your compiler supports C99,
769 you can override the test by passing ac_cv_prog_cc_c99= as an argument
770 to the configure script. The test for C99 compiler is not perfect (and
771 it is not as easy to make it perfect as it sounds), so sometimes this
772 may be needed. You will get a compile error if your compiler doesn't
776 5.2. "No POSIX conforming shell (sh) was found."
778 xzgrep and other scripts need a shell that (roughly) conforms
779 to POSIX. The configure script tries to find such a shell. If
780 it fails, you can force the shell to be used by passing
781 gl_cv_posix_shell=/path/to/posix-sh as an argument to the configure
782 script. Alternatively you can omit the installation of scripts and
783 this error by passing --disable-scripts to configure.
786 5.3. configure works but build fails at crc32_x86.S
788 The easy fix is to pass --disable-assembler to the configure script.
790 The configure script determines if assembler code can be used by
791 looking at the configure triplet; there is currently no check if
792 the assembler code can actually actually be built. The x86 assembler
793 code should work on x86 GNU/Linux, *BSDs, Solaris, Darwin, MinGW,
794 Cygwin, and DJGPP. On other x86 systems, there may be problems and
795 the assembler code may need to be disabled with the configure option.
797 If you get this error when building for x86-64, you have specified or
798 the configure script has misguessed your architecture. Pass the
799 correct configure triplet using the --build=CPU-COMPANY-SYSTEM option
800 (see INSTALL.generic).
803 5.4. Lots of warnings about symbol visibility
805 On some systems where symbol visibility isn't supported, GCC may
806 still accept the visibility options and attributes, which will make
807 configure think that visibility is supported. This will result in
808 many compiler warnings. You can avoid the warnings by forcing the
809 visibility support off by passing gl_cv_cc_visibility=no as an
810 argument to the configure script. This has no effect on the
811 resulting binaries, but fewer warnings looks nicer and may allow
812 using --enable-werror.
815 5.5. "make check" fails
817 If the other tests pass but test_scripts.sh fails, then the problem
818 is in the scripts in src/scripts. Comparing the contents of
819 tests/xzgrep_test_output to tests/xzgrep_expected_output might
820 give a good idea about problems in xzgrep. One possibility is that
821 some tools are missing from the current PATH or the tools lack
822 support for some POSIX features. This can happen at least on
823 Solaris where the tools in /bin may be ancient but good enough
824 tools are available in /usr/xpg4/bin or /usr/xpg6/bin. For possible
825 fixes, see --enable-path-for-scripts=PREFIX in section 2 and the
826 older alternative method described in section 3.2 of this file.
828 If tests other than test_scripts.sh fail, a likely reason is that
829 libtool links the test programs against an installed version of
830 liblzma instead of the version that was just built. This is
831 obviously a bug which seems to happen on some platforms.
832 A workaround is to uninstall the old liblzma versions first.
834 If the problem isn't any of those described above, then it's likely
835 a bug in XZ Utils or in the compiler. See the platform-specific
836 notes in this file for possible known problems. Please report
837 a bug if you cannot solve the problem. See README for contact
841 5.6. liblzma.so (or similar) not found when running xz
843 If you installed the package with "make install" and get an error
844 about liblzma.so (or a similarly named file) being missing, try
845 running "ldconfig" to update the run-time linker cache (if your
846 operating system has such a command).