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.2.6. OpenVMS

       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.

    To omit large number of harmless warnings about visibility support,

    pass gl_cv_cc_visibility=no as an argument to the configure script.

    This isn't mandatory since it should have no effect on the resulting

    binaries.

1.2.6. OpenVMS

    XZ Utils can be built for OpenVMS, but the build system files are

    currently 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.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.

                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 to set the default memory usage limit.

                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 32 MiB, which is probably too low for most

                systems, but it is enough to allow decompressing .xz files

                created with the default settings.

                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.

    --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=TYPE

                Specify how command line tools should be linked against

                liblzma. Possible TYPES:

                    yes     All command line tools are linked against

                            shared liblzma (if shared liblzma was built).

                            This is equivalent to --enable-dynamic (i.e.

                            no =TYPE).

                    mixed   Some tools are linked against static liblzma

                            and some against shared liblzma. This is the

                            default and recommended way.

                    no      All command line tools are linked against

                            static liblzma (if static liblzma was built).

                            This is equivalent to --disable-dynamic.

                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).