Index: INSTALL |
=================================================================== |
--- INSTALL (revision 50504) |
+++ INSTALL (working copy) |
@@ -7,20 +7,24 @@ |
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 |
@@ -65,22 +69,62 @@ |
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 |
@@ -94,7 +138,7 @@ |
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 |
@@ -104,24 +148,6 @@ |
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 +165,7 @@ |
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 +218,29 @@ |
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 |
@@ -235,13 +284,14 @@ |
--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 |
@@ -258,28 +308,6 @@ |
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 |
@@ -292,6 +320,52 @@ |
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 |
--------------------------- |
@@ -342,7 +416,7 @@ |
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 |
@@ -351,7 +425,7 @@ |
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. |
@@ -367,3 +441,15 @@ |
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. |
+ |