6b44b4a775
Now liblzma only uses "mythread" functions and types which are defined in mythread.h matching the desired threading method. Before Windows Vista, there is no direct equivalent to pthread condition variables. Since this package doesn't use pthread_cond_broadcast(), pre-Vista threading can still be kept quite simple. The pre-Vista code doesn't use anything that wasn't already available in Windows 95, so the binaries should run even on Windows 95 if someone happens to care.
492 lines
20 KiB
Plaintext
492 lines
20 KiB
Plaintext
|
|
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.3. Adding support for new platforms
|
|
2. configure 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. Troubleshooting
|
|
4.1. "No C99 compiler was found."
|
|
4.2. "No POSIX conforming shell (sh) was found."
|
|
4.3. configure works but build fails at crc32_x86.S
|
|
4.4. Lots of warnings about symbol visibility
|
|
|
|
|
|
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
|
|
|
|
The default install of MINIX 3 includes Amsterdam Compiler Kit (ACK),
|
|
which doesn't support C99. Install GCC to compile XZ Utils.
|
|
|
|
MINIX 3.1.8 and older have bugs in /usr/include/stdint.h, which has
|
|
to be patched before XZ Utils can be compiled correctly. See
|
|
<http://gforge.cs.vu.nl/gf/project/minix/tracker/?action=TrackerItemEdit&tracker_item_id=537>.
|
|
|
|
MINIX 3.2.0 and later use a different libc and aren't affected by
|
|
the above bug.
|
|
|
|
XZ Utils doesn't have code to detect the amount of physical RAM and
|
|
number of CPU cores on MINIX 3.
|
|
|
|
See section 4.4 in this file about symbol visibility warnings (you
|
|
may want to pass gl_cv_cc_visibility=no to configure).
|
|
|
|
|
|
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://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.
|
|
|
|
|
|
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 4.1 in
|
|
this file (pass also ac_cv_prog_cc_c99= to configure).
|
|
|
|
|
|
1.2.7. Windows
|
|
|
|
Building XZ Utils on Windows is supported under MinGW + MSYS,
|
|
MinGW-w64 + MSYS, and Cygwin. There is windows/build.bash to
|
|
ease packaging XZ Utils with MinGW(-w64) + MSYS into a
|
|
redistributable .zip or .7z file. See windows/INSTALL-Windows.txt
|
|
for more information.
|
|
|
|
It might be possible to build liblzma with a non-GNU toolchain too,
|
|
but that will probably require writing a separate makefile. Building
|
|
the command line tools with non-GNU toolchains will be harder than
|
|
building only liblzma.
|
|
|
|
Even if liblzma is built with MinGW, the resulting DLL or static
|
|
library can be used by other compilers and linkers, including MSVC.
|
|
Thus, it shouldn't be a problem to use MinGW to build liblzma even
|
|
if you cannot use MinGW to build the rest of your project. See
|
|
windows/README-Windows.txt for details.
|
|
|
|
|
|
1.2.8. DOS
|
|
|
|
There is an experimental Makefile in the "dos" directory to build
|
|
XZ Utils on DOS using DJGPP. Support for long file names (LFN) is
|
|
needed. See dos/README for more information.
|
|
|
|
GNU Autotools based build hasn't been tried on DOS. If you try, I
|
|
would like to hear if it worked.
|
|
|
|
|
|
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 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.
|
|
|
|
--enable-encoders=LIST
|
|
--disable-encoders
|
|
Specify a comma-separated LIST of filter encoders to
|
|
build. See "./configure --help" for exact list of
|
|
available filter encoders. 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
|
|
This is like --enable-encoders but for decoders. The
|
|
default is to build all supported decoders.
|
|
|
|
--enable-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
|
|
liblzma support multiple integrity checks. CRC32 is
|
|
mandatory, and cannot be omitted. See "./configure --help"
|
|
for exact list of available integrity check types.
|
|
|
|
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.
|
|
|
|
--disable-xz
|
|
--disable-xzdec
|
|
--disable-lzmadec
|
|
--disable-lzmainfo
|
|
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.
|
|
|
|
--disable-lzma-links
|
|
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
|
|
Don't install the scripts xzdiff, xzgrep, xzmore, xzless,
|
|
and their symlinks.
|
|
|
|
--disable-assembler
|
|
liblzma includes some assembler optimizations. Currently
|
|
there is only assembler code for CRC32 and CRC64 for
|
|
32-bit x86.
|
|
|
|
All the assembler code in liblzma is position-independent
|
|
code, which is suitable for use in shared libraries and
|
|
position-independent executables. So far only i386
|
|
instructions are used, 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.
|
|
|
|
--enable-unaligned-access
|
|
Allow liblzma to use unaligned memory access for 16-bit
|
|
and 32-bit loads and stores. This should be enabled only
|
|
when the hardware supports this, i.e. 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 x86, x86-64,
|
|
and big endian PowerPC.
|
|
|
|
--enable-small
|
|
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
|
|
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
|
|
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. 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, 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-symbol-versions
|
|
Use symbol versioning for liblzma. This is enabled by
|
|
default on GNU/Linux, other GNU-based systems, and
|
|
FreeBSD.
|
|
|
|
--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.
|
|
|
|
--enable-werror
|
|
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.
|
|
|
|
|
|
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.
|
|
E.g. 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.
|
|
|
|
Some of the scripts require also mktemp. The original mktemp can be
|
|
found from <http://www.mktemp.org/>. On GNU, most will use the mktemp
|
|
program from GNU coreutils instead of the original implementation.
|
|
Both mktemp versions are fine for XZ Utils (and practically for
|
|
everything else too).
|
|
|
|
|
|
3.2. PATH
|
|
|
|
The scripts assume that the required tools (standard POSIX utilities,
|
|
mktemp, and xz) are in PATH; the scripts don't set the PATH themselves.
|
|
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. Troubleshooting
|
|
------------------
|
|
|
|
4.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.
|
|
|
|
|
|
4.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.
|
|
|
|
|
|
4.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 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).
|
|
|
|
|
|
4.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.
|
|
|