forked from tukaani-project/xz
-
Notifications
You must be signed in to change notification settings - Fork 0
/
INSTALL
944 lines (717 loc) · 39.8 KB
/
INSTALL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
XZ Utils Installation
=====================
0. Preface
1. Supported platforms
1.1. Compilers
1.2. Platform-specific notes
1.2.1. AIX
1.2.2. IRIX
1.2.3. MINIX 3
1.2.4. OpenVMS
1.2.5. Solaris, OpenSolaris, and derivatives
1.2.6. Tru64
1.2.7. Windows
1.2.8. DOS
1.2.9. z/OS
1.3. Adding support for new platforms
2. configure and CMake options
2.1. Static vs. dynamic linking of liblzma
2.2. Optimizing xzdec and lzmadec
3. xzgrep and other scripts
3.1. Dependencies
3.2. PATH
4. Tests
4.1 Testing in parallel
4.2 Cross compiling
5. Troubleshooting
5.1. "No C99 compiler was found."
5.2. "No POSIX conforming shell (sh) was found."
5.3. configure works but build fails at crc32_x86.S
5.4. Lots of warnings about symbol visibility
5.5. "make check" fails
5.6. liblzma.so (or similar) not found when running xz
0. Preface
----------
If you aren't familiar with building packages that use GNU Autotools,
see the file INSTALL.generic for generic instructions before reading
further.
If you are going to build a package for distribution, see also the
file PACKAGERS. It contains information that should help making the
binary packages as good as possible, but the information isn't very
interesting to those making local builds for private use or for use
in special situations like embedded systems.
1. Supported platforms
----------------------
XZ Utils are developed on GNU/Linux, but they should work on many
POSIX-like operating systems like *BSDs and Solaris, and even on
a few non-POSIX operating systems.
1.1. Compilers
A C99 compiler is required to compile XZ Utils. If you use GCC, you
need at least version 3.x.x. GCC version 2.xx.x doesn't support some
C99 features used in XZ Utils source code, thus GCC 2 won't compile
XZ Utils.
XZ Utils takes advantage of some GNU C extensions when building
with GCC. Because these extensions are used only when building
with GCC, it should be possible to use any C99 compiler.
1.2. Platform-specific notes
1.2.1. AIX
If you use IBM XL C compiler, pass CC=xlc_r to configure. If
you use CC=xlc instead, you must disable threading support
with --disable-threads (usually not recommended).
1.2.2. IRIX
MIPSpro 7.4.4m has been reported to produce broken code if using
the -O2 optimization flag ("make check" fails). Using -O1 should
work.
A problem has been reported when using shared liblzma. Passing
--disable-shared to configure works around this. Alternatively,
putting "-64" to CFLAGS to build a 64-bit version might help too.
1.2.3. MINIX 3
Version 3.3.0 and later are supported.
Multithreading isn't supported because MINIX 3 doesn't have
pthreads. The option --disable-threads must be passed to configure
as this isn't autodetected.
Note that disabling threads causes "make check" to show a few tests
as skipped ("SKIP"). It's only due to a few threading-dependent
subtests are skipped. See the matching tests/test_*.log files.
1.2.4. OpenVMS
XZ Utils can be built for OpenVMS, but the build system files
are not included in the XZ Utils source package. The required
OpenVMS-specific files are maintained by Jouk Jansen and can be
downloaded here:
http:https://nchrem.tnw.tudelft.nl/openvms/software2.html#xzutils
1.2.5. Solaris, OpenSolaris, and derivatives
The following linker error has been reported on some x86 systems:
ld: fatal: relocation error: R_386_GOTOFF: ...
This can be worked around by passing gl_cv_cc_visibility=no
as an argument to the configure script.
test_scripts.sh in "make check" may fail if good enough tools are
missing from PATH (/usr/xpg4/bin or /usr/xpg6/bin). Nowadays
/usr/xpg4/bin is added to the script PATH by default on Solaris
(see --enable-path-for-scripts=PREFIX in section 2), but old xz
releases needed extra steps. See sections 5.5 and 3.2 for more
information.
1.2.6. Tru64
If you try to use the native C compiler on Tru64 (passing CC=cc to
configure), you may need the workaround mention in section 5.1 in
this file (pass also ac_cv_prog_cc_c99= to configure).
1.2.7. Windows
The "windows" directory contains instructions for a few types
of builds:
- INSTALL-MinGW-w64_with_CMake.txt
Simple instructions how to build XZ Utils natively on
Windows using only CMake and a prebuilt toolchain
(GCC + MinGW-w64 or Clang/LLVM + MinGW-w64).
- INSTALL-MinGW-w64_with_Autotools.txt
Native build under MSYS2 or cross-compilation from
GNU/Linux using a bash script that creates a .zip
and .7z archives of the binaries and documentation.
The related file README-Windows.txt is for the
resulting binary package.
- INSTALL-MSVC.txt
Building with MSVC / Visual Studio and CMake.
- liblzma-crt-mixing.txt
Documentation what to take into account as a programmer
if liblzma.dll and the application don't use the same
CRT (MSVCRT or UCRT).
Other choices:
- Cygwin: https://cygwin.com/
Building on Cygwin can be done like on many POSIX operating
systems. XZ Utils >= 5.2.0 isn't compatible with Cygwin older
than 1.7.35 (data loss!). 1.7.35 was released on 2015-03-04.
- MSYS2: https://www.msys2.org/
1.2.8. DOS
There is a Makefile in the "dos" directory to build XZ Utils on
DOS using DJGPP. Support for long file names (LFN) is needed at
build time but the resulting xz.exe works without LFN support too.
See dos/INSTALL.txt and dos/README.txt for more information.
1.2.9. z/OS
To build XZ Utils on z/OS UNIX System Services using xlc, pass
these options to the configure script: CC='xlc -qhaltonmsg=CCN3296'
CPPFLAS='-D_UNIX03_THREADS -D_XOPEN_SOURCE=600'. The first makes
xlc throw an error if a header file is missing, which is required
to make the tests in configure work. The CPPFLAGS are needed to
get pthread support (some other CPPFLAGS may work too; if there
are problems, try -D_UNIX95_THREADS instead of -D_UNIX03_THREADS).
test_scripts.sh in "make check" will fail even if the scripts
actually work because the test data includes compressed files
with US-ASCII text.
No other tests should fail. If test_files.sh fails, check that
the included .xz test files weren't affected by EBCDIC conversion.
XZ Utils doesn't have code to detect the amount of physical RAM and
number of CPU cores on z/OS.
1.3. Adding support for new platforms
If you have written patches to make XZ Utils to work on previously
unsupported platform, please send the patches to me! I will consider
including them to the official version. It's nice to minimize the
need of third-party patching.
One exception: Don't request or send patches to change the whole
source package to C89. I find C99 substantially nicer to write and
maintain. However, the public library headers must be in C89 to
avoid frustrating those who maintain programs, which are strictly
in C89 or C++.
2. configure and CMake options
------------------------------
In most cases, the defaults are what you want. Many of the options
below are useful only when building a size-optimized version of
liblzma or command line tools.
configure options are those that begin with two dashes "--"
or "gl_".
CMake options begin with "XZ_", "TUKLIB_", or "CMAKE_". To use
them on the command line, prefix them with "-D", for example,
"cmake -DCMAKE_COMPILE_WARNING_AS_ERROR=ON".
CMAKE_BUILD_TYPE=TYPE
CMake only:
For release builds, CMAKE_BUILD_TYPE=Release is fine.
On targets where CMake defaults to -O3, the default
value is overridden to -O2.
Empty value (CMAKE_BUILD_TYPE=) is fine if using custom
optimization options. *In this package* the empty build
type also disables debugging code just like "Release"
does. To enable debugging code with empty build type,
use -UNDEBUG in the CFLAGS environment variable or in
the CMAKE_C_FLAGS CMake variable to override -DNDEBUG.
Non-standard build types like "None" do NOT disable
debugging code! Such non-standard build types should
be avoided for production builds!
--enable-encoders=LIST
--disable-encoders
XZ_ENCODERS=LIST
Specify a LIST of filter encoders to build. In the
configure option the list is comma separated.
CMake lists are semicolon separated.
To see the exact list of available filter encoders:
- Autotools: ./configure --help
- CMake: Configure the tree normally first, then use
"cmake -LH ." to list the cache variables.
The default is to build all supported encoders.
If LIST is empty or --disable-encoders is used, no filter
encoders will be built and also the code shared between
encoders will be omitted.
Disabling encoders will remove some symbols from the
liblzma ABI, so this option should be used only when it
is known to not cause problems.
--enable-decoders=LIST
--disable-decoders
XZ_DECODERS=LIST
This is like --enable-encoders but for decoders. The
default is to build all supported decoders.
--enable-match-finders=LIST
XZ_MATCH_FINDERS=LIST
liblzma includes two categories of match finders:
hash chains and binary trees. Hash chains (hc3 and hc4)
are quite fast but they don't provide the best compression
ratio. Binary trees (bt2, bt3 and bt4) give excellent
compression ratio, but they are slower and need more
memory than hash chains.
You need to enable at least one match finder to build the
LZMA1 or LZMA2 filter encoders. Usually hash chains are
used only in the fast mode, while binary trees are used to
when the best compression ratio is wanted.
The default is to build all the match finders if LZMA1
or LZMA2 filter encoders are being built.
--enable-checks=LIST
XZ_CHECKS=LIST
liblzma support multiple integrity checks. CRC32 is
mandatory, and cannot be omitted. Supported check
types are "crc32", "crc64", and "sha256". By default
all supported check types are enabled.
liblzma and the command line tools can decompress files
which use unsupported integrity check type, but naturally
the file integrity cannot be verified in that case.
Disabling integrity checks may remove some symbols from
the liblzma ABI, so this option should be used only when
it is known to not cause problems.
--enable-external-sha256
XZ_EXTERNAL_SHA256=ON
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-microlzma
XZ_MICROLZMA_ENCODER=OFF
XZ_MICROLZMA_DECODER=OFF
Don't build MicroLZMA encoder and decoder. This omits
lzma_microlzma_encoder() and lzma_microlzma_decoder()
API functions from liblzma. These functions are needed
by specific applications only. They were written for
erofs-utils but they may be used by others too.
--disable-lzip-decoder
XZ_LZIP_DECODER=OFF
Disable decompression support for .lz (lzip) files.
This omits the API function lzma_lzip_decoder() from
liblzma and .lz support from the xz tool.
--disable-xz
--disable-xzdec
--disable-lzmadec
--disable-lzmainfo
XZ_TOOL_XZ=OFF
XZ_TOOL_XZDEC=OFF
XZ_TOOL_LZMADEC=OFF
XZ_TOOL_LZMAINFO=OFF
Don't build and install the command line tool mentioned
in the option name.
NOTE: Disabling xz will skip some tests in "make check".
NOTE: If xzdec is disabled and lzmadec is left enabled,
a dangling man page symlink lzmadec.1 -> xzdec.1 is
created.
XZ_TOOL_SYMLINKS=OFF
Don't create the unxz and xzcat symlinks. (There is
no "configure" option to disable these symlinks.)
--disable-lzma-links
XZ_TOOL_SYMLINKS_LZMA=OFF
Don't create symlinks for LZMA Utils compatibility.
This includes lzma, unlzma, and lzcat. If scripts are
installed, also lzdiff, lzcmp, lzgrep, lzegrep, lzfgrep,
lzmore, and lzless will be omitted if this option is used.
--disable-scripts
XZ_TOOL_SCRIPTS=OFF
Don't install the scripts xzdiff, xzgrep, xzmore, xzless,
and their symlinks.
--disable-doc
XZ_DOC=OFF
Don't install the documentation files to $docdir
(often /usr/doc/xz or /usr/local/doc/xz). Man pages
will still be installed. The $docdir can be changed
with --docdir=DIR.
--enable-doxygen
XZ_DOXYGEN=ON
Enable generation of the HTML version of the liblzma API
documentation using Doxygen. The resulting files are
installed to $docdir/api. This option assumes that
the 'doxygen' tool is available.
NOTE: --disable-doc or XZ_DOC=OFF don't affect this.
--disable-assembler
XZ_ASM_I386=OFF
This disables CRC32 and CRC64 assembly code on
32-bit x86. This option currently does nothing
on other architectures (not even on x86-64).
The 32-bit x86 assembly is position-independent code
which is suitable for use in shared libraries and
position-independent executables. It uses only i386
instructions but the code is optimized for i686 class
CPUs. If you are compiling liblzma exclusively for
pre-i686 systems, you may want to disable the assembler
code.
The assembly code is compatible with only certain OSes
and toolchains (it's not compatible with MSVC).
Since XZ Utils 5.7.1alpha, the 32-bit x86 assembly code
co-exists with the modern CLMUL code: CLMUL is used if
support for it is detected at runtime. On old processors
the assembly code is used.
--disable-clmul-crc
XZ_CLMUL_CRC=OFF
Disable the use of carryless multiplication for CRC
calculation even if compiler support for it is detected.
The code uses runtime detection of SSSE3, SSE4.1, and
CLMUL instructions on x86. On 32-bit x86 this currently
is used only if --disable-assembler is used (this might
be fixed in the future). The code works on E2K too.
If using compiler options that unconditionally allow the
required extensions (-msse4.1 -mpclmul) then runtime
detection isn't used and the generic code is omitted.
--disable-arm64-crc32
XZ_ARM64_CRC32=OFF
Disable the use of the ARM64 CRC32 instruction extension
even if compiler support for it is detected. The code will
detect support for the instruction at runtime.
If using compiler options that unconditionally allow the
required extensions (-march=armv8-a+crc or -march=armv8.1-a
and later) then runtime detection isn't used and the
generic code is omitted.
--enable-unaligned-access
TUKLIB_FAST_UNALIGNED_ACCESS=ON
Allow liblzma to use unaligned memory access for 16-bit,
32-bit, and 64-bit loads and stores. This should be
enabled only when the hardware supports this, that is,
when unaligned access is fast. Some operating system
kernels emulate unaligned access, which is extremely
slow. This option shouldn't be used on systems that
rely on such emulation.
Unaligned access is enabled by default on these:
- 32-bit x86
- 64-bit x86-64
- 32-bit big endian PowerPC
- 64-bit big endian PowerPC
- 64-bit little endian PowerPC
- some RISC-V [1]
- some 32-bit ARM [2]
- some 64-bit ARM64 [2] (NOTE: Autodetection bug
if using GCC -mstrict-align, see below.)
[1] Unaligned access is enabled by default if
configure sees that the C compiler
#defines __riscv_misaligned_fast.
[2] Unaligned access is enabled by default if
configure sees that the C compiler
#defines __ARM_FEATURE_UNALIGNED:
- ARMv7 + GCC or Clang: It works. The options
-munaligned-access and -mno-unaligned-access
affect this macro correctly.
- ARM64 + Clang: It works. The options
-munaligned-access, -mno-unaligned-access,
and -mstrict-align affect this macro correctly.
Clang >= 17 supports -mno-strict-align too.
- ARM64 + GCC: It partially works. The macro
is always #defined by GCC versions at least
up to 13.2, even when using -mstrict-align.
If building for strict-align ARM64, the
configure option --disable-unaligned-access
should be used if using a GCC version that has
this issue because otherwise the performance
may be degraded. It likely won't crash due to
how unaligned access is done in the C code.
--enable-unsafe-type-punning
TUKLIB_USE_UNSAFE_TYPE_PUNNING=ON
This enables use of code like
uint8_t *buf8 = ...;
*(uint32_t *)buf8 = ...;
which violates strict aliasing rules and may result
in broken code. There should be no need to use this
option with recent GCC or Clang versions on any
arch as just as fast code can be generated in a safe
way too (using __builtin_assume_aligned + memcpy).
However, this option might improve performance in some
other cases, especially with old compilers (for example,
GCC 3 and early 4.x on x86, GCC < 6 on ARMv6 and ARMv7).
--enable-small
XZ_SMALL=ON
Reduce the size of liblzma by selecting smaller but
semantically equivalent version of some functions, and
omit precomputed lookup tables. This option tends to
make liblzma slightly slower.
Note that while omitting the precomputed tables makes
liblzma smaller on disk, the tables are still needed at
run time, and need to be computed at startup. This also
means that the RAM holding the tables won't be shared
between applications linked against shared liblzma.
This option doesn't modify CFLAGS to tell the compiler
to optimize for size. You need to add -Os or equivalent
flag(s) to CFLAGS manually.
--enable-assume-ram=SIZE
XZ_ASSUME_RAM=SIZE
On the most common operating systems, XZ Utils is able to
detect the amount of physical memory on the system. This
information is used by the options --memlimit-compress,
--memlimit-decompress, and --memlimit when setting the
limit to a percentage of total RAM.
On some systems, there is no code to detect the amount of
RAM though. Using --enable-assume-ram one can set how much
memory to assume on these systems. SIZE is given as MiB.
The default is 128 MiB.
Feel free to send patches to add support for detecting
the amount of RAM on the operating system you use. See
src/common/tuklib_physmem.c for details.
--enable-threads=METHOD
XZ_THREADS=METHOD
Threading support is enabled by default so normally there
is no need to specify this option.
Supported values for METHOD:
yes Autodetect the threading method. If none
is found, configure will give an error.
posix Use POSIX pthreads. This is the default
except on Windows outside Cygwin.
win95 Use Windows 95 compatible threads. This
is compatible with Windows XP and later
too. This is the default for 32-bit x86
Windows builds. Unless the compiler
supports __attribute__((__constructor__)),
the 'win95' threading is incompatible with
--enable-small.
vista Use Windows Vista compatible threads. The
resulting binaries won't run on Windows XP
or older. This is the default for Windows
excluding 32-bit x86 builds (that is, on
x86-64 the default is 'vista').
no Disable threading support. This is the
same as using --disable-threads.
NOTE: If combined with --enable-small
and the compiler doesn't support
__attribute__((__constructor__)), the
resulting liblzma won't be thread safe,
that is, if a multi-threaded application
calls any liblzma functions from more than
one thread, something bad may happen.
--enable-sandbox=METHOD
XZ_SANDBOX=METHOD
There is limited sandboxing support in the xz and xzdec
tools. If built with sandbox support, xz uses it
automatically when (de)compressing exactly one file to
standard output when the options --files or --files0 aren't
used. This is a common use case, for example,
(de)compressing .tar.xz files via GNU tar. The sandbox is
also used for single-file 'xz --test' or 'xz --list'.
xzdec always uses the sandbox, except when more than one
file are decompressed. In this case it will enable the
sandbox for the last file that is decompressed.
Supported METHODs:
auto Look for a supported sandboxing method
and use it if found. If no method is
found, then sandboxing isn't used.
This is the default.
no Disable sandboxing support.
capsicum
Use Capsicum (FreeBSD >= 10.2) for
sandboxing. If no Capsicum support
is found, configure will give an error.
pledge Use pledge(2) (OpenBSD >= 5.9) for
sandboxing. If pledge(2) isn't found,
configure will give an error.
landlock
Use Landlock (Linux >= 5.13) for
sandboxing. If no Landlock support
is found, configure will give an error.
--enable-symbol-versions[=VARIANT]
XZ_SYMBOL_VERSIONING=VARIANT
Use symbol versioning for liblzma shared library.
This is enabled by default on GNU/Linux (glibc only),
other GNU-based systems, and FreeBSD.
Symbol versioning is never used for static liblzma. This
option is ignored when not building a shared library.
Supported VARIANTs:
no Disable symbol versioning. This is the
same as using --disable-symbol-versions.
auto Autodetect between "no", "linux",
and "generic".
yes Autodetect between "linux" and
"generic". This forces symbol
versioning to be used when
building a shared library.
generic Generic version is the default for
FreeBSD and GNU/Linux on MicroBlaze.
This is also used on GNU/Linux when
building with NVIDIA HPC Compiler
because the compiler doesn't support
the features required for the "linux"
variant below.
linux Special version for GNU/Linux (glibc
only). This adds a few extra symbol
versions for compatibility with binaries
that have been linked against a liblzma
version that has been patched with
"xz-5.2.2-compat-libs.patch" from
RHEL/CentOS 7. That patch was used
by some build tools outside of
RHEL/CentOS 7 too.
--enable-debug
This enables the assert() macro and possibly some other
run-time consistency checks. It makes the code slower, so
you normally don't want to have this enabled.
In CMake, the build type (CMAKE_BUILD_TYPE) controls if
-DNDEBUG is passed to the compiler. *In this package*,
an empty build type disables debugging code too.
Non-standard build types like "None" do NOT disable
debugging code!
To enable debugging code with empty build type in CMake,
use -UNDEBUG in the CFLAGS environment variable or in
the CMAKE_C_FLAGS CMake variable to override -DNDEBUG.
--enable-werror
CMAKE_COMPILE_WARNING_AS_ERROR=ON (CMake >= 3.24)
If building with GCC, make all compiler warnings an error,
that abort the compilation. This may help catching bugs,
and should work on most systems. This has no effect on the
resulting binaries.
--enable-path-for-scripts=PREFIX
(CMake determines this from the path of XZ_POSIX_SHELL)
If PREFIX isn't empty, PATH=PREFIX:$PATH will be set in
the beginning of the scripts (xzgrep and others).
The default is empty except on Solaris the default is
/usr/xpg4/bin.
This can be useful if the default PATH doesn't contain
modern POSIX tools (as can be the case on Solaris) or if
one wants to ensure that the correct xz binary is in the
PATH for the scripts. Note that the latter use can break
"make check" if the prefixed PATH causes a wrong xz binary
(other than the one that was just built) to be used.
Older xz releases support a different method for setting
the PATH for the scripts. It is described in section 3.2
and is supported in this xz version too.
gl_cv_posix_shell=/path/to/bin/sh
XZ_POSIX_SHELL=/path/to/bin/sh
POSIX shell to use for xzgrep and other scripts.
- configure should autodetect this well enough.
Typically it's /bin/sh but in some cases, like
Solaris, something else is used.
- CMake build uses /bin/sh except on Solaris the
default is /usr/xpg4/bin/sh.
2.1. Static vs. dynamic linking of liblzma
On 32-bit x86, linking against static liblzma can give a minor
speed improvement. Static libraries on x86 are usually compiled as
position-dependent code (non-PIC) and shared libraries are built as
position-independent code (PIC). PIC wastes one register, which can
make the code slightly slower compared to a non-PIC version. (Note
that this doesn't apply to x86-64.)
If you want to link xz against static liblzma, the simplest way
is to pass --disable-shared to configure. If you want also shared
liblzma, run configure again and run "make install" only for
src/liblzma.
2.2. Optimizing xzdec and lzmadec
xzdec and lzmadec are intended to be relatively small instead of
optimizing for the best speed. Thus, it is a good idea to build
xzdec and lzmadec separately:
- To link the tools against static liblzma, pass --disable-shared
to configure.
- To select somewhat size-optimized variant of some things in
liblzma, pass --enable-small to configure.
- Tell the compiler to optimize for size instead of speed.
For example, with GCC, put -Os into CFLAGS.
- xzdec and lzmadec will never use multithreading capabilities of
liblzma. You can avoid dependency on libpthread by passing
--disable-threads to configure.
- There are and will be no translated messages for xzdec and
lzmadec, so it is fine to pass also --disable-nls to configure.
- Only decoder code is needed, so you can speed up the build
slightly by passing --disable-encoders to configure. This
shouldn't affect the final size of the executables though,
because the linker is able to omit the encoder code anyway.
If you have no use for xzdec or lzmadec, you can disable them with
--disable-xzdec and --disable-lzmadec.
3. xzgrep and other scripts
---------------------------
3.1. Dependencies
POSIX shell (sh) and bunch of other standard POSIX tools are required
to run the scripts. The configure script tries to find a POSIX
compliant sh, but if it fails, you can force the shell by passing
gl_cv_posix_shell=/path/to/posix-sh as an argument to the configure
script.
xzdiff (xzcmp/lzdiff/lzcmp) may use mktemp if it is available. As
a fallback xzdiff will use mkdir to securely create a temporary
directory. Having mktemp available is still recommended since the
mkdir fallback method isn't as robust as mktemp is. The original
mktemp can be found from <https://www.mktemp.org/>. On GNU, most will
use the mktemp program from GNU coreutils instead of the original
implementation. Both mktemp versions are fine.
In addition to using xz to decompress .xz files, xzgrep and xzdiff
use gzip, bzip2, and lzop to support .gz, bz2, and .lzo files.
3.2. PATH
The method described below is supported by older xz releases.
It is supported by the current version too, but the newer
--enable-path-for-scripts=PREFIX described in section 2 may be
more convenient.
The scripts assume that the required tools (standard POSIX utilities,
mktemp, and xz) are in PATH; the scripts don't set the PATH themselves
(except as described for --enable-path-for-scripts=PREFIX). Some
people like this while some think this is a bug. Those in the latter
group can easily patch the scripts before running the configure script
by taking advantage of a placeholder line in the scripts.
For example, to make the scripts prefix /usr/bin:/bin to PATH:
perl -pi -e 's|^#SET_PATH.*$|PATH=/usr/bin:/bin:\$PATH|' \
src/scripts/xz*.in
4. Tests
--------
The test framework can be built and run by executing "make check" in
the build directory. The tests are a mix of executables and POSIX
shell scripts (sh). All tests should pass if the default configuration
is used. Disabling features through the configure options may cause
some tests to be skipped. If any tests do not pass, see section 5.5.
4.1. Testing in parallel
The tests can be run in parallel using the "-j" make option on systems
that support it. For instance, "make -j4 check" will run up to four
tests simultaneously.
4.2. Cross compiling
The tests can be built without running them:
make check TESTS=
The TESTS variable is the list of tests you wish to run. Leaving it
empty will compile the tests without running any.
If the tests are copied to a target machine to execute, the test data
files in the directory tests/files must also be copied. The tests
search for the data files using the environment variable $srcdir,
expecting to find the data files under $srcdir/files/. If $srcdir
isn't set then it defaults to the current directory.
The shell script tests can be copied from the source directory to the
target machine to execute. In addition to the test files, these tests
will expect the following relative file paths to execute properly:
./create_compress_files
../config.h
../src/xz/xz
../src/xzdec/xzdec
../src/scripts/xzdiff
../src/scripts/xzgrep
5. Troubleshooting
------------------
5.1. "No C99 compiler was found."
You need a C99 compiler to build XZ Utils. If the configure script
cannot find a C99 compiler and you think you have such a compiler
installed, set the compiler command by passing CC=/path/to/c99 as
an argument to the configure script.
If you get this error even when you think your compiler supports C99,
you can override the test by passing ac_cv_prog_cc_c99= as an argument
to the configure script. The test for C99 compiler is not perfect (and
it is not as easy to make it perfect as it sounds), so sometimes this
may be needed. You will get a compile error if your compiler doesn't
support enough C99.
5.2. "No POSIX conforming shell (sh) was found."
xzgrep and other scripts need a shell that (roughly) conforms
to POSIX. The configure script tries to find such a shell. If
it fails, you can force the shell to be used by passing
gl_cv_posix_shell=/path/to/posix-sh as an argument to the configure
script. Alternatively you can omit the installation of scripts and
this error by passing --disable-scripts to configure.
5.3. configure works but build fails at crc32_x86.S
The easy fix is to pass --disable-assembler to the configure script.
The configure script determines if assembler code can be used by
looking at the configure triplet; there is currently no check if
the assembler code can actually be built. The x86 assembler
code should work on x86 GNU/Linux, *BSDs, Solaris, Darwin, MinGW,
Cygwin, and DJGPP. On other x86 systems, there may be problems and
the assembler code may need to be disabled with the configure option.
If you get this error when building for x86-64, you have specified or
the configure script has misguessed your architecture. Pass the
correct configure triplet using the --build=CPU-COMPANY-SYSTEM option
(see INSTALL.generic).
5.4. Lots of warnings about symbol visibility
On some systems where symbol visibility isn't supported, GCC may
still accept the visibility options and attributes, which will make
configure think that visibility is supported. This will result in
many compiler warnings. You can avoid the warnings by forcing the
visibility support off by passing gl_cv_cc_visibility=no as an
argument to the configure script. This has no effect on the
resulting binaries, but fewer warnings looks nicer and may allow
using --enable-werror.
5.5. "make check" fails
If the other tests pass but test_scripts.sh fails, then the problem
is in the scripts in src/scripts. Comparing the contents of
tests/xzgrep_test_output to tests/xzgrep_expected_output might
give a good idea about problems in xzgrep. One possibility is that
some tools are missing from the current PATH or the tools lack
support for some POSIX features. This can happen at least on
Solaris where the tools in /bin may be ancient but good enough
tools are available in /usr/xpg4/bin or /usr/xpg6/bin. For possible
fixes, see --enable-path-for-scripts=PREFIX in section 2 and the
older alternative method described in section 3.2 of this file.
If tests other than test_scripts.sh fail, a likely reason is that
libtool links the test programs against an installed version of
liblzma instead of the version that was just built. This is
obviously a bug which seems to happen on some platforms.
A workaround is to uninstall the old liblzma versions first.
If the problem isn't any of those described above, then it's likely
a bug in XZ Utils or in the compiler. See the platform-specific
notes in this file for possible known problems. Please report
a bug if you cannot solve the problem. See README for contact
information.
5.6. liblzma.so (or similar) not found when running xz
If you installed the package with "make install" and get an error
about liblzma.so (or a similarly named file) being missing, try
running "ldconfig" to update the run-time linker cache (if your
operating system has such a command).