| blob | bf1e9c31529586aabb894ee81503e211b6989896 |
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. Troubleshooting
26 4.1. "No C99 compiler was found."
27 4.2. "No POSIX conforming shell (sh) was found."
28 4.3. configure works but build fails at crc32_x86.S
29 4.4. Lots of warnings about symbol visibility
30 4.5. "make check" fails
31 4.6. liblzma.so (or similar) not found when running xz
34 0. Preface
35 ----------
37 If you aren't familiar with building packages that use GNU Autotools,
38 see the file INSTALL.generic for generic instructions before reading
39 further.
41 If you are going to build a package for distribution, see also the
42 file PACKAGERS. It contains information that should help making the
43 binary packages as good as possible, but the information isn't very
44 interesting to those making local builds for private use or for use
45 in special situations like embedded systems.
48 1. Supported platforms
49 ----------------------
51 XZ Utils are developed on GNU/Linux, but they should work on many
52 POSIX-like operating systems like *BSDs and Solaris, and even on
53 a few non-POSIX operating systems.
56 1.1. Compilers
58 A C99 compiler is required to compile XZ Utils. If you use GCC, you
59 need at least version 3.x.x. GCC version 2.xx.x doesn't support some
60 C99 features used in XZ Utils source code, thus GCC 2 won't compile
61 XZ Utils.
63 XZ Utils takes advantage of some GNU C extensions when building
64 with GCC. Because these extensions are used only when building
65 with GCC, it should be possible to use any C99 compiler.
68 1.2. Platform-specific notes
70 1.2.1. AIX
72 If you use IBM XL C compiler, pass CC=xlc_r to configure. If
73 you use CC=xlc instead, you must disable threading support
74 with --disable-threads (usually not recommended).
77 1.2.2. IRIX
79 MIPSpro 7.4.4m has been reported to produce broken code if using
80 the -O2 optimization flag ("make check" fails). Using -O1 should
81 work.
83 A problem has been reported when using shared liblzma. Passing
84 --disable-shared to configure works around this. Alternatively,
85 putting "-64" to CFLAGS to build a 64-bit version might help too.
88 1.2.3. MINIX 3
90 The default install of MINIX 3 includes Amsterdam Compiler Kit (ACK),
91 which doesn't support C99. Install GCC to compile XZ Utils.
93 MINIX 3.1.8 and older have bugs in /usr/include/stdint.h, which has
94 to be patched before XZ Utils can be compiled correctly. See
95 <http://gforge.cs.vu.nl/gf/project/minix/tracker/?action=TrackerItemEdit&tracker_item_id=537>.
97 MINIX 3.2.0 and later use a different libc and aren't affected by
98 the above bug.
100 XZ Utils doesn't have code to detect the amount of physical RAM and
101 number of CPU cores on MINIX 3.
103 See section 4.4 in this file about symbol visibility warnings (you
104 may want to pass gl_cv_cc_visibility=no to configure).
107 1.2.4. OpenVMS
109 XZ Utils can be built for OpenVMS, but the build system files
110 are not included in the XZ Utils source package. The required
111 OpenVMS-specific files are maintained by Jouk Jansen and can be
112 downloaded here:
114 http://nchrem.tnw.tudelft.nl/openvms/software2.html#xzutils
117 1.2.5. Solaris, OpenSolaris, and derivatives
119 The following linker error has been reported on some x86 systems:
121 ld: fatal: relocation error: R_386_GOTOFF: ...
123 This can be worked around by passing gl_cv_cc_visibility=no
124 as an argument to the configure script.
126 test_scripts.sh in "make check" may fail if good enough tools are
127 missing from PATH (/usr/xpg4/bin or /usr/xpg6/bin). Nowadays
128 /usr/xpg4/bin is added to the script PATH by default on Solaris
129 (see --enable-path-for-scripts=PREFIX in section 2), but old xz
130 releases needed extra steps. See sections 4.5 and 3.2 for more
131 information.
134 1.2.6. Tru64
136 If you try to use the native C compiler on Tru64 (passing CC=cc to
137 configure), you may need the workaround mention in section 4.1 in
138 this file (pass also ac_cv_prog_cc_c99= to configure).
141 1.2.7. Windows
143 If it is enough to build liblzma (no command line tools):
145 - There is experimental CMake support. As it is, it should be
146 good enough to build static liblzma with Visual Studio.
147 Building liblzma.dll might work too (if it doesn't, it should
148 be fixed). The CMake support may work with MinGW or MinGW-w64.
149 Read the comment in the beginning of CMakeLists.txt before
150 running CMake!
152 - There are Visual Studio project files under the "windows"
153 directory. See windows/INSTALL-MSVC.txt. In the future the
154 project files will be removed when CMake support is good
155 enough. Thus, please test the CMake version and help fix
156 possible issues.
158 To build also the command line tools:
160 - MinGW-w64 + MSYS (32-bit and 64-bit x86): This is used
161 for building the official binary packages for Windows.
162 There is windows/build.bash to ease packaging XZ Utils with
163 MinGW(-w64) + MSYS into a redistributable .zip or .7z file.
164 See windows/INSTALL-MinGW.txt for more information.
166 - MinGW + MSYS (32-bit x86): I haven't recently tested this.
168 - Cygwin 1.7.35 and later: NOTE that using XZ Utils >= 5.2.0
169 under Cygwin older than 1.7.35 can lead to DATA LOSS! If
170 you must use an old Cygwin version, stick to XZ Utils 5.0.x
171 which is safe under older Cygwin versions. You can check
172 the Cygwin version with the command "cygcheck -V".
174 It may be possible to build liblzma with other toolchains too, but
175 that will probably require writing a separate makefile. Building
176 the command line tools with non-GNU toolchains will be harder than
177 building only liblzma.
179 Even if liblzma is built with MinGW(-w64), the resulting DLL can
180 be used by other compilers and linkers, including MSVC. See
181 windows/README-Windows.txt for details.
184 1.2.8. DOS
186 There is a Makefile in the "dos" directory to build XZ Utils on
187 DOS using DJGPP. Support for long file names (LFN) is needed at
188 build time but the resulting xz.exe works without LFN support too.
189 See dos/INSTALL.txt and dos/README.txt for more information.
192 1.2.9. z/OS
194 To build XZ Utils on z/OS UNIX System Services using xlc, pass
195 these options to the configure script: CC='xlc -qhaltonmsg=CCN3296'
196 CPPFLAS='-D_UNIX03_THREADS -D_XOPEN_SOURCE=600'. The first makes
197 xlc throw an error if a header file is missing, which is required
198 to make the tests in configure work. The CPPFLAGS are needed to
199 get pthread support (some other CPPFLAGS may work too; if there
200 are problems, try -D_UNIX95_THREADS instead of -D_UNIX03_THREADS).
202 test_scripts.sh in "make check" will fail even if the scripts
203 actually work because the test data includes compressed files
204 with US-ASCII text.
206 No other tests should fail. If test_files.sh fails, check that
207 the included .xz test files weren't affected by EBCDIC conversion.
209 XZ Utils doesn't have code to detect the amount of physical RAM and
210 number of CPU cores on z/OS.
213 1.3. Adding support for new platforms
215 If you have written patches to make XZ Utils to work on previously
216 unsupported platform, please send the patches to me! I will consider
217 including them to the official version. It's nice to minimize the
218 need of third-party patching.
220 One exception: Don't request or send patches to change the whole
221 source package to C89. I find C99 substantially nicer to write and
222 maintain. However, the public library headers must be in C89 to
223 avoid frustrating those who maintain programs, which are strictly
224 in C89 or C++.
227 2. configure options
228 --------------------
230 In most cases, the defaults are what you want. Many of the options
231 below are useful only when building a size-optimized version of
232 liblzma or command line tools.
234 --enable-encoders=LIST
235 --disable-encoders
236 Specify a comma-separated LIST of filter encoders to
237 build. See "./configure --help" for exact list of
238 available filter encoders. The default is to build all
239 supported encoders.
241 If LIST is empty or --disable-encoders is used, no filter
242 encoders will be built and also the code shared between
243 encoders will be omitted.
245 Disabling encoders will remove some symbols from the
246 liblzma ABI, so this option should be used only when it
247 is known to not cause problems.
249 --enable-decoders=LIST
250 --disable-decoders
251 This is like --enable-encoders but for decoders. The
252 default is to build all supported decoders.
254 --enable-match-finders=LIST
255 liblzma includes two categories of match finders:
256 hash chains and binary trees. Hash chains (hc3 and hc4)
257 are quite fast but they don't provide the best compression
258 ratio. Binary trees (bt2, bt3 and bt4) give excellent
259 compression ratio, but they are slower and need more
260 memory than hash chains.
262 You need to enable at least one match finder to build the
263 LZMA1 or LZMA2 filter encoders. Usually hash chains are
264 used only in the fast mode, while binary trees are used to
265 when the best compression ratio is wanted.
267 The default is to build all the match finders if LZMA1
268 or LZMA2 filter encoders are being built.
270 --enable-checks=LIST
271 liblzma support multiple integrity checks. CRC32 is
272 mandatory, and cannot be omitted. See "./configure --help"
273 for exact list of available integrity check types.
275 liblzma and the command line tools can decompress files
276 which use unsupported integrity check type, but naturally
277 the file integrity cannot be verified in that case.
279 Disabling integrity checks may remove some symbols from
280 the liblzma ABI, so this option should be used only when
281 it is known to not cause problems.
283 --enable-external-sha256
284 Try to use SHA-256 code from the operating system libc
285 or similar base system libraries. This doesn't try to
286 use OpenSSL or libgcrypt or such libraries.
288 The reasons to use this option:
290 - It makes liblzma slightly smaller.
292 - It might improve SHA-256 speed if the implementation
293 in the operating is very good (but see below).
295 External SHA-256 is disabled by default for two reasons:
297 - On some operating systems the symbol names of the
298 SHA-256 functions conflict with OpenSSL's libcrypto.
299 This causes weird problems such as decompression
300 errors if an application is linked against both
301 liblzma and libcrypto. This problem affects at least
302 FreeBSD 10 and older and MINIX 3.3.0 and older, but
303 other OSes that provide a function "SHA256_Init" might
304 also be affected. FreeBSD 11 has the problem fixed.
305 NetBSD had the problem but it was fixed it in 2009
306 already. OpenBSD uses "SHA256Init" and thus never had
307 a conflict with libcrypto.
309 - The SHA-256 code in liblzma is faster than the SHA-256
310 code provided by some operating systems. If you are
311 curious, build two copies of xz (internal and external
312 SHA-256) and compare the decompression (xz --test)
313 times:
315 dd if=/dev/zero bs=1024k count=1024 \
316 | xz -v -0 -Csha256 > foo.xz
317 time xz --test foo.xz
319 --disable-microlzma
320 Don't build MicroLZMA encoder and decoder. This omits
321 lzma_microlzma_encoder() and lzma_microlzma_decoder()
322 API functions from liblzma. These functions are needed
323 by specific applications only. They were written for
324 erofs-utils but they may be used by others too.
326 --disable-lzip-decoder
327 Disable decompression support for .lz (lzip) files.
328 This omits the API function lzma_lzip_decoder() from
329 liblzma and .lz support from the xz tool.
331 --disable-xz
332 --disable-xzdec
333 --disable-lzmadec
334 --disable-lzmainfo
335 Don't build and install the command line tool mentioned
336 in the option name.
338 NOTE: Disabling xz will skip some tests in "make check".
340 NOTE: If xzdec is disabled and lzmadec is left enabled,
341 a dangling man page symlink lzmadec.1 -> xzdec.1 is
342 created.
344 --disable-lzma-links
345 Don't create symlinks for LZMA Utils compatibility.
346 This includes lzma, unlzma, and lzcat. If scripts are
347 installed, also lzdiff, lzcmp, lzgrep, lzegrep, lzfgrep,
348 lzmore, and lzless will be omitted if this option is used.
350 --disable-scripts
351 Don't install the scripts xzdiff, xzgrep, xzmore, xzless,
352 and their symlinks.
354 --disable-doc
355 Don't install the documentation files to $docdir
356 (often /usr/doc/xz or /usr/local/doc/xz). Man pages
357 will still be installed. The $docdir can be changed
358 with --docdir=DIR.
360 --disable-assembler
361 liblzma includes some assembler optimizations. Currently
362 there is only assembler code for CRC32 and CRC64 for
363 32-bit x86.
365 All the assembler code in liblzma is position-independent
366 code, which is suitable for use in shared libraries and
367 position-independent executables. So far only i386
368 instructions are used, but the code is optimized for i686
369 class CPUs. If you are compiling liblzma exclusively for
370 pre-i686 systems, you may want to disable the assembler
371 code.
373 --disable-clmul-crc
374 Disable the use carryless multiplication for CRC
375 calculation even if compiler support for it is detected.
376 The code uses runtime detection of SSSE3, SSE4.1, and
377 CLMUL instructions on x86. On 32-bit x86 this currently
378 is used only if --disable-assembler is used (this might
379 be fixed in the future). The code works on E2K too.
381 If using compiler options that unconditionally allow the
382 required extensions (-msse4.1 -mpclmul) then runtime
383 detection isn't used and the generic code is omitted.
385 --enable-unaligned-access
386 Allow liblzma to use unaligned memory access for 16-bit,
387 32-bit, and 64-bit loads and stores. This should be
388 enabled only when the hardware supports this, that is,
389 when unaligned access is fast. Some operating system
390 kernels emulate unaligned access, which is extremely
391 slow. This option shouldn't be used on systems that
392 rely on such emulation.
394 Unaligned access is enabled by default on x86, x86-64,
395 big endian PowerPC, some ARM, and some ARM64 systems.
397 --enable-unsafe-type-punning
398 This enables use of code like
400 uint8_t *buf8 = ...;
401 *(uint32_t *)buf8 = ...;
403 which violates strict aliasing rules and may result
404 in broken code. There should be no need to use this
405 option with recent GCC or Clang versions on any
406 arch as just as fast code can be generated in a safe
407 way too (using __builtin_assume_aligned + memcpy).
409 However, this option might improve performance in some
410 other cases, especially with old compilers (for example,
411 GCC 3 and early 4.x on x86, GCC < 6 on ARMv6 and ARMv7).
413 --enable-small
414 Reduce the size of liblzma by selecting smaller but
415 semantically equivalent version of some functions, and
416 omit precomputed lookup tables. This option tends to
417 make liblzma slightly slower.
419 Note that while omitting the precomputed tables makes
420 liblzma smaller on disk, the tables are still needed at
421 run time, and need to be computed at startup. This also
422 means that the RAM holding the tables won't be shared
423 between applications linked against shared liblzma.
425 This option doesn't modify CFLAGS to tell the compiler
426 to optimize for size. You need to add -Os or equivalent
427 flag(s) to CFLAGS manually.
429 --enable-assume-ram=SIZE
430 On the most common operating systems, XZ Utils is able to
431 detect the amount of physical memory on the system. This
432 information is used by the options --memlimit-compress,
433 --memlimit-decompress, and --memlimit when setting the
434 limit to a percentage of total RAM.
436 On some systems, there is no code to detect the amount of
437 RAM though. Using --enable-assume-ram one can set how much
438 memory to assume on these systems. SIZE is given as MiB.
439 The default is 128 MiB.
441 Feel free to send patches to add support for detecting
442 the amount of RAM on the operating system you use. See
443 src/common/tuklib_physmem.c for details.
445 --enable-threads=METHOD
446 Threading support is enabled by default so normally there
447 is no need to specify this option.
449 Supported values for METHOD:
451 yes Autodetect the threading method. If none
452 is found, configure will give an error.
454 posix Use POSIX pthreads. This is the default
455 except on Windows outside Cygwin.
457 win95 Use Windows 95 compatible threads. This
458 is compatible with Windows XP and later
459 too. This is the default for 32-bit x86
460 Windows builds. The `win95' threading is
461 incompatible with --enable-small.
463 vista Use Windows Vista compatible threads. The
464 resulting binaries won't run on Windows XP
465 or older. This is the default for Windows
466 excluding 32-bit x86 builds (that is, on
467 x86-64 the default is `vista').
469 no Disable threading support. This is the
470 same as using --disable-threads.
471 NOTE: If combined with --enable-small
472 and the compiler doesn't support
473 __attribute__((__constructor__)), the
474 resulting liblzma won't be thread safe,
475 that is, if a multi-threaded application
476 calls any liblzma functions from more than
477 one thread, something bad may happen.
479 --enable-sandbox=METHOD
480 There is limited sandboxing support in the xz tool. If
481 built with sandbox support, it's used automatically when
482 (de)compressing exactly one file to standard output and
483 the options --files or --files0 weren't used. This is a
484 common use case, for example, (de)compressing .tar.xz
485 files via GNU tar. The sandbox is also used for
486 single-file `xz --test' or `xz --list'.
488 Supported METHODs:
490 auto Look for a supported sandboxing method
491 and use it if found. If no method is
492 found, then sandboxing isn't used.
493 This is the default.
495 no Disable sandboxing support.
497 capsicum
498 Use Capsicum (FreeBSD >= 10) for
499 sandboxing. If no Capsicum support
500 is found, configure will give an error.
502 pledge Use pledge(2) (OpenBSD >= 5.9) for
503 sandboxing. If pledge(2) isn't found,
504 configure will give an error.
506 --enable-symbol-versions
507 Use symbol versioning for liblzma. This is enabled by
508 default on GNU/Linux, other GNU-based systems, and
509 FreeBSD.
511 --enable-debug
512 This enables the assert() macro and possibly some other
513 run-time consistency checks. It makes the code slower, so
514 you normally don't want to have this enabled.
516 --enable-werror
517 If building with GCC, make all compiler warnings an error,
518 that abort the compilation. This may help catching bugs,
519 and should work on most systems. This has no effect on the
520 resulting binaries.
522 --enable-path-for-scripts=PREFIX
523 If PREFIX isn't empty, PATH=PREFIX:$PATH will be set in
524 the beginning of the scripts (xzgrep and others).
525 The default is empty except on Solaris the default is
526 /usr/xpg4/bin.
528 This can be useful if the default PATH doesn't contain
529 modern POSIX tools (as can be the case on Solaris) or if
530 one wants to ensure that the correct xz binary is in the
531 PATH for the scripts. Note that the latter use can break
532 "make check" if the prefixed PATH causes a wrong xz binary
533 (other than the one that was just built) to be used.
535 Older xz releases support a different method for setting
536 the PATH for the scripts. It is described in section 3.2
537 and is supported in this xz version too.
540 2.1. Static vs. dynamic linking of liblzma
542 On 32-bit x86, linking against static liblzma can give a minor
543 speed improvement. Static libraries on x86 are usually compiled as
544 position-dependent code (non-PIC) and shared libraries are built as
545 position-independent code (PIC). PIC wastes one register, which can
546 make the code slightly slower compared to a non-PIC version. (Note
547 that this doesn't apply to x86-64.)
549 If you want to link xz against static liblzma, the simplest way
550 is to pass --disable-shared to configure. If you want also shared
551 liblzma, run configure again and run "make install" only for
552 src/liblzma.
555 2.2. Optimizing xzdec and lzmadec
557 xzdec and lzmadec are intended to be relatively small instead of
558 optimizing for the best speed. Thus, it is a good idea to build
559 xzdec and lzmadec separately:
561 - To link the tools against static liblzma, pass --disable-shared
562 to configure.
564 - To select somewhat size-optimized variant of some things in
565 liblzma, pass --enable-small to configure.
567 - Tell the compiler to optimize for size instead of speed.
568 For example, with GCC, put -Os into CFLAGS.
570 - xzdec and lzmadec will never use multithreading capabilities of
571 liblzma. You can avoid dependency on libpthread by passing
572 --disable-threads to configure.
574 - There are and will be no translated messages for xzdec and
575 lzmadec, so it is fine to pass also --disable-nls to configure.
577 - Only decoder code is needed, so you can speed up the build
578 slightly by passing --disable-encoders to configure. This
579 shouldn't affect the final size of the executables though,
580 because the linker is able to omit the encoder code anyway.
582 If you have no use for xzdec or lzmadec, you can disable them with
583 --disable-xzdec and --disable-lzmadec.
586 3. xzgrep and other scripts
587 ---------------------------
589 3.1. Dependencies
591 POSIX shell (sh) and bunch of other standard POSIX tools are required
592 to run the scripts. The configure script tries to find a POSIX
593 compliant sh, but if it fails, you can force the shell by passing
594 gl_cv_posix_shell=/path/to/posix-sh as an argument to the configure
595 script.
597 xzdiff (xzcmp/lzdiff/lzcmp) may use mktemp if it is available. As
598 a fallback xzdiff will use mkdir to securely create a temporary
599 directory. Having mktemp available is still recommended since the
600 mkdir fallback method isn't as robust as mktemp is. The original
601 mktemp can be found from <http://www.mktemp.org/>. On GNU, most will
602 use the mktemp program from GNU coreutils instead of the original
603 implementation. Both mktemp versions are fine.
605 In addition to using xz to decompress .xz files, xzgrep and xzdiff
606 use gzip, bzip2, and lzop to support .gz, bz2, and .lzo files.
609 3.2. PATH
611 The method described below is supported by older xz releases.
612 It is supported by the current version too, but the newer
613 --enable-path-for-scripts=PREFIX described in section 2 may be
614 more convenient.
616 The scripts assume that the required tools (standard POSIX utilities,
617 mktemp, and xz) are in PATH; the scripts don't set the PATH themselves
618 (except as described for --enable-path-for-scripts=PREFIX). Some
619 people like this while some think this is a bug. Those in the latter
620 group can easily patch the scripts before running the configure script
621 by taking advantage of a placeholder line in the scripts.
623 For example, to make the scripts prefix /usr/bin:/bin to PATH:
625 perl -pi -e 's|^#SET_PATH.*$|PATH=/usr/bin:/bin:\$PATH|' \
626 src/scripts/xz*.in
629 4. Troubleshooting
630 ------------------
632 4.1. "No C99 compiler was found."
634 You need a C99 compiler to build XZ Utils. If the configure script
635 cannot find a C99 compiler and you think you have such a compiler
636 installed, set the compiler command by passing CC=/path/to/c99 as
637 an argument to the configure script.
639 If you get this error even when you think your compiler supports C99,
640 you can override the test by passing ac_cv_prog_cc_c99= as an argument
641 to the configure script. The test for C99 compiler is not perfect (and
642 it is not as easy to make it perfect as it sounds), so sometimes this
643 may be needed. You will get a compile error if your compiler doesn't
644 support enough C99.
647 4.2. "No POSIX conforming shell (sh) was found."
649 xzgrep and other scripts need a shell that (roughly) conforms
650 to POSIX. The configure script tries to find such a shell. If
651 it fails, you can force the shell to be used by passing
652 gl_cv_posix_shell=/path/to/posix-sh as an argument to the configure
653 script. Alternatively you can omit the installation of scripts and
654 this error by passing --disable-scripts to configure.
657 4.3. configure works but build fails at crc32_x86.S
659 The easy fix is to pass --disable-assembler to the configure script.
661 The configure script determines if assembler code can be used by
662 looking at the configure triplet; there is currently no check if
663 the assembler code can actually actually be built. The x86 assembler
664 code should work on x86 GNU/Linux, *BSDs, Solaris, Darwin, MinGW,
665 Cygwin, and DJGPP. On other x86 systems, there may be problems and
666 the assembler code may need to be disabled with the configure option.
668 If you get this error when building for x86-64, you have specified or
669 the configure script has misguessed your architecture. Pass the
670 correct configure triplet using the --build=CPU-COMPANY-SYSTEM option
671 (see INSTALL.generic).
674 4.4. Lots of warnings about symbol visibility
676 On some systems where symbol visibility isn't supported, GCC may
677 still accept the visibility options and attributes, which will make
678 configure think that visibility is supported. This will result in
679 many compiler warnings. You can avoid the warnings by forcing the
680 visibility support off by passing gl_cv_cc_visibility=no as an
681 argument to the configure script. This has no effect on the
682 resulting binaries, but fewer warnings looks nicer and may allow
683 using --enable-werror.
686 4.5. "make check" fails
688 If the other tests pass but test_scripts.sh fails, then the problem
689 is in the scripts in src/scripts. Comparing the contents of
690 tests/xzgrep_test_output to tests/xzgrep_expected_output might
691 give a good idea about problems in xzgrep. One possibility is that
692 some tools are missing from the current PATH or the tools lack
693 support for some POSIX features. This can happen at least on
694 Solaris where the tools in /bin may be ancient but good enough
695 tools are available in /usr/xpg4/bin or /usr/xpg6/bin. For possible
696 fixes, see --enable-path-for-scripts=PREFIX in section 2 and the
697 older alternative method described in section 3.2 of this file.
699 If tests other than test_scripts.sh fail, a likely reason is that
700 libtool links the test programs against an installed version of
701 liblzma instead of the version that was just built. This is
702 obviously a bug which seems to happen on some platforms.
703 A workaround is to uninstall the old liblzma versions first.
705 If the problem isn't any of those described above, then it's likely
706 a bug in XZ Utils or in the compiler. See the platform-specific
707 notes in this file for possible known problems. Please report
708 a bug if you cannot solve the problem. See README for contact
709 information.
712 4.6. liblzma.so (or similar) not found when running xz
714 If you installed the package with "make install" and get an error
715 about liblzma.so (or a similarly named file) being missing, try
716 running "ldconfig" to update the run-time linker cache (if your
717 operating system has such a command).