Update docs.

1 files changed, 131 insertions, 61 deletions

diff --git a/INSTALL b/INSTALL
index 5cd69a8..339fedb 100644
--- a/INSTALL
+++ b/INSTALL
@@ -7,20 +7,23 @@ XZ Utils Installation
        1.1. Compilers
        1.2. Platform-specific notes
             1.2.1. IRIX
-            1.2.2. Tru64
-            1.2.3. Windows
-            1.2.4. DOS
-            1.2.5. OS/2
-            1.2.6. OpenVMS
+            1.2.2. MINIX 3
+            1.2.3. OpenVMS
+            1.2.4. Tru64
+            1.2.5. Windows
+            1.2.6. 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.1. "No POSIX conforming shell (sh) was found."
-       4.2. configure works but build fails at crc32_x86.S
+       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
@@ -66,21 +69,47 @@ XZ Utils Installation
     work.
 
 
-1.2.2. Tru64
+1.2.2. 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 possibly some other versions too) has 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>.
+
+    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.3. 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.4. 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.
+    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.3. Windows
+1.2.5. Windows
 
-    Building XZ Utils on Windows is supported under MinGW + MSYS and
-    Cygwin. There is windows/build.bash to ease packaging XZ Utils with
-    MinGW + MSYS into a redistributable .zip or .7z file. See
-    windows/INSTALL-Windows.txt for more information.
+    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
@@ -94,7 +123,7 @@ XZ Utils Installation
     windows/README-Windows.txt for details.
 
 
-1.2.4. DOS
+1.2.6. 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
@@ -104,24 +133,6 @@ XZ Utils Installation
     would like to hear if it worked.
 
 
-1.2.5. 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
@@ -139,7 +150,7 @@ XZ Utils Installation
 2. configure options
 --------------------
 
-    In most cases, the defaults are what you want. Most of the 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.
 
@@ -192,6 +203,29 @@ XZ Utils Installation
                 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
@@ -259,28 +293,6 @@ XZ Utils Installation
                 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
@@ -293,6 +305,52 @@ XZ Utils Installation
                 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
 ---------------------------
 
@@ -343,7 +401,7 @@ XZ Utils Installation
     support enough C99.
 
 
-4.1. "No POSIX conforming shell (sh) was found."
+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
@@ -352,7 +410,7 @@ XZ Utils Installation
     script.
 
 
-4.2. configure works but build fails at crc32_x86.S
+4.3. configure works but build fails at crc32_x86.S
 
     The easy fix is to pass --disable-assembler to the configure script.
 
@@ -368,3 +426,15 @@ XZ Utils Installation
     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.
+