diff options
Diffstat (limited to 'Build/source/extra/xz-4.999.9beta/INSTALL')
| -rw-r--r-- | Build/source/extra/xz-4.999.9beta/INSTALL | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/Build/source/extra/xz-4.999.9beta/INSTALL b/Build/source/extra/xz-4.999.9beta/INSTALL new file mode 100644 index 00000000000..ec757202c98 --- /dev/null +++ b/Build/source/extra/xz-4.999.9beta/INSTALL @@ -0,0 +1,339 @@ + +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=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). + |