revi-archive/xz-archive
1
0
Fork 0
mirror of https://git.tukaani.org/xz.git synced 2024-04-04 12:36:23 +02:00
Code Activity
xz-archive/INSTALL
Lasse Collin 99f9e879a6 Major documentation update. 
Installation and packaging instructions were added.
README and other generic docs were revised.

Some of the documentation files are now installed to $docdir.
2009-07-19 13:14:20 +03:00

327 lines
13 KiB
Text
Raw Blame History

XZ Utils Installation
=====================
0. Preface
1. Supported platforms
1.1. Compilers
1.2. Platform-specific notes
1.2.1. Darwin (Mac OS X)
1.2.2. Tru64
1.2.3. Windows
1.2.4. DOS
1.2.5. OS/2
1.3. Adding support for new platforms
2. configure options
3. xzgrep and other scripts
3.1. Dependencies
3.2. PATH
4. Troubleshooting
4.1. "No C99 compiler was found."
4.1. "No POSIX conforming shell (sh) was found."
4.2. configure works but build fails at crc32_x86.S
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. Darwin (Mac OS X)
You may need --disable-assembler if building universal binaries on
Darwin. This is because different files are built when assembler is
enabled, and there's no way to make it work with universal build.
If you want to keep the assembler code, consider building one
architecture at a time, and then combining the results to create
universal binaries (see lipo(1)).
1.2.2. Tru64
If you try to use the native C compiler on Tru64 (passing CC=cc to
configure), it is possible that the configure script will complain
that no C99 compiler was found even when the native compiler supports
C99. You can safely override the test for C99 compiler by passing
ac_cv_prog_cc_c99= as the argument to the configure script.
1.2.3. Windows
Building XZ Utils on Windows is supported under MinGW and Cygwin.
If the Autotools based build gives you trouble with MinGW, you may
want try the alternative method found from the "windows" directory.
MSVC doesn't support C99, thus it is not possible to use MSVC to
compile XZ Utils. However, it is possible to use liblzma.dll from
MSVC once liblzma.dll has been built with MinGW. The required
import library for MSVC can be created from liblzma.def using the
"lib" command shipped in MSVC:
lib /def:liblzma.def /out:liblzma.lib /machine:ix86
On x86-64, the /machine argument has to naturally be changed:
lib /def:liblzma.def /out:liblzma.lib /machine:x64
1.2.4. 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.
GNU Autotools based build hasn't been tried on DOS.
1.2.5. OS/2
You will need to pass --disable-assembler to configure when building
on OS/2.
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. Most 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-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.
--disable-threads
Disable threading support. This makes some things
thread-unsafe, meaning that if multithreaded application
calls liblzma functions from more than one thread,
something bad may happen.
Use this option if threading support causes you trouble,
or if you know that you will use liblzma only from
single-threaded applications and want to avoid dependency
on libpthread.
--enable-dynamic
Link the command line tools against shared liblzma. The
default (and recommended way) is to link the command line
tools against static liblzma.
This option is mostly useful for packagers, if distro
policy requires linking against shared libaries. See the
file PACKAGERS for more information about pros and cons
of this option.
--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.
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.1. "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.2. 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).
View git blame Copy permalink