Update XZ Utils to 5.0.3 (in deps)

INSTALL

 
 XZ Utils Installation
 =====================
 
     0. Preface
     1. Supported platforms
        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. Solaris, OpenSolaris, and derivatives
+            1.2.5. Tru64
+            1.2.6. Windows
+            1.2.7. 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
 ----------
 
     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
@@ skipping 24 matching lines @@
 
 
 1.2. Platform-specific notes
 
 1.2.1. 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.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. 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.5. 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.6. Windows
 
-    Building XZ Utils on Windows is supported under MinGW + MSYS and
-    Cygwin. There is windows/build.sh 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
     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.4. DOS
+1.2.7. 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.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
     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
+    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.
 
@@ skipping 32 matching lines @@
                 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
@@ skipping 23 matching lines @@
                 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.
+                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, which allows decompressing files
-                created with "xz -9".
+                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.
 
     --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.
 
 
+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.
@@ skipping 30 matching lines @@
     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."
+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.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.
 
     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.
+