INSTALL   INSTALL 
skipping to change at line 29 skipping to change at line 29
2.1. Static vs. dynamic linking of liblzma 2.1. Static vs. dynamic linking of liblzma
2.2. Optimizing xzdec and lzmadec 2.2. Optimizing xzdec and lzmadec
3. xzgrep and other scripts 3. xzgrep and other scripts
3.1. Dependencies 3.1. Dependencies
3.2. PATH 3.2. PATH
4. Troubleshooting 4. Troubleshooting
4.1. "No C99 compiler was found." 4.1. "No C99 compiler was found."
4.2. "No POSIX conforming shell (sh) was found." 4.2. "No POSIX conforming shell (sh) was found."
4.3. configure works but build fails at crc32_x86.S 4.3. configure works but build fails at crc32_x86.S
4.4. Lots of warnings about symbol visibility 4.4. Lots of warnings about symbol visibility
4.5. "make check" fails
4.6. liblzma.so (or similar) not found when running xz
0. Preface 0. Preface
---------- ----------
If you aren't familiar with building packages that use GNU Autotools, If you aren't familiar with building packages that use GNU Autotools,
see the file INSTALL.generic for generic instructions before reading see the file INSTALL.generic for generic instructions before reading
further. further.
If you are going to build a package for distribution, see also the If you are going to build a package for distribution, see also the
file PACKAGERS. It contains information that should help making the file PACKAGERS. It contains information that should help making the
skipping to change at line 129 skipping to change at line 131
this file (pass also ac_cv_prog_cc_c99= to configure). this file (pass also ac_cv_prog_cc_c99= to configure).
1.2.7. Windows 1.2.7. Windows
Building XZ Utils on Windows is supported under MinGW + MSYS, Building XZ Utils on Windows is supported under MinGW + MSYS,
MinGW-w64 + MSYS, and Cygwin. There is windows/build.bash to MinGW-w64 + MSYS, and Cygwin. There is windows/build.bash to
ease packaging XZ Utils with MinGW(-w64) + MSYS into a ease packaging XZ Utils with MinGW(-w64) + MSYS into a
redistributable .zip or .7z file. See windows/INSTALL-Windows.txt redistributable .zip or .7z file. See windows/INSTALL-Windows.txt
for more information. for more information.
It might be possible to build liblzma with a non-GNU toolchain too, It may be possible to build liblzma with other toolchains too, but
but that will probably require writing a separate makefile. Building that will probably require writing a separate makefile. Building
the command line tools with non-GNU toolchains will be harder than the command line tools with non-GNU toolchains will be harder than
building only liblzma. building only liblzma.
Even if liblzma is built with MinGW, the resulting DLL or static Starting with XZ Utils 5.2.0, building liblzma (not the whole
library can be used by other compilers and linkers, including MSVC. XZ Utils) should work with MSVC 2013 update 2 or later using
Thus, it shouldn't be a problem to use MinGW to build liblzma even windows/config.h. No project files or makefiles are included yet,
if you cannot use MinGW to build the rest of your project. See so the build process isn't as convenient yet as it could be.
Even if liblzma is built with MinGW(-w64), the resulting DLL can
be used by other compilers and linkers, including MSVC. See
windows/README-Windows.txt for details. windows/README-Windows.txt for details.
1.2.8. DOS 1.2.8. DOS
There is an experimental Makefile in the "dos" directory to build There is an experimental Makefile in the "dos" directory to build
XZ Utils on DOS using DJGPP. Support for long file names (LFN) is XZ Utils on DOS using DJGPP. Support for long file names (LFN) is
needed. See dos/README for more information. needed. See dos/README for more information.
GNU Autotools based build hasn't been tried on DOS. If you try, I GNU Autotools based build hasn't been tried on DOS. If you try, I
would like to hear if it worked. would like to hear if it worked.
skipping to change at line 241 skipping to change at line 246
--disable-lzma-links --disable-lzma-links
Don't create symlinks for LZMA Utils compatibility. Don't create symlinks for LZMA Utils compatibility.
This includes lzma, unlzma, and lzcat. If scripts are This includes lzma, unlzma, and lzcat. If scripts are
installed, also lzdiff, lzcmp, lzgrep, lzegrep, lzfgrep, installed, also lzdiff, lzcmp, lzgrep, lzegrep, lzfgrep,
lzmore, and lzless will be omitted if this option is used. lzmore, and lzless will be omitted if this option is used.
--disable-scripts --disable-scripts
Don't install the scripts xzdiff, xzgrep, xzmore, xzless, Don't install the scripts xzdiff, xzgrep, xzmore, xzless,
and their symlinks. and their symlinks.
--disable-doc
Don't install the documentation files to $docdir
(often /usr/doc/xz or /usr/local/doc/xz). Man pages
will still be installed. The $docdir can be changed
with --docdir=DIR.
--disable-assembler --disable-assembler
liblzma includes some assembler optimizations. Currently liblzma includes some assembler optimizations. Currently
there is only assembler code for CRC32 and CRC64 for there is only assembler code for CRC32 and CRC64 for
32-bit x86. 32-bit x86.
All the assembler code in liblzma is position-independent All the assembler code in liblzma is position-independent
code, which is suitable for use in shared libraries and code, which is suitable for use in shared libraries and
position-independent executables. So far only i386 position-independent executables. So far only i386
instructions are used, but the code is optimized for i686 instructions are used, but the code is optimized for i686
class CPUs. If you are compiling liblzma exclusively for class CPUs. If you are compiling liblzma exclusively for
skipping to change at line 297 skipping to change at line 308
On some systems, there is no code to detect the amount of On some systems, there is no code to detect the amount of
RAM though. Using --enable-assume-ram one can set how much RAM though. Using --enable-assume-ram one can set how much
memory to assume on these systems. SIZE is given as MiB. memory to assume on these systems. SIZE is given as MiB.
The default is 128 MiB. The default is 128 MiB.
Feel free to send patches to add support for detecting Feel free to send patches to add support for detecting
the amount of RAM on the operating system you use. See the amount of RAM on the operating system you use. See
src/common/tuklib_physmem.c for details. src/common/tuklib_physmem.c for details.
--disable-threads --enable-threads=METHOD
Disable threading support. This makes some things Threading support is enabled by default so normally there
thread-unsafe, meaning that if multithreaded application is no need to specify this option.
calls liblzma functions from more than one thread,
something bad may happen. Supported values for METHOD:
Use this option if threading support causes you trouble, yes Autodetect the threading method. If none
or if you know that you will use liblzma only from is found, configure will give an error.
single-threaded applications and want to avoid dependency
on libpthread. posix Use POSIX pthreads. This is the default
except on Windows outside Cygwin.
win95 Use Windows 95 compatible threads. This
is compatible with Windows XP and later
too. This is the default for 32-bit x86
Windows builds. The `win95' threading is
incompatible with --enable-small.
vista Use Windows Vista compatible threads. The
resulting binaries won't run on Windows XP
or older. This is the default for Windows
excluding 32-bit x86 builds (that is, on
x86-64 the default is `vista').
no Disable threading support. This is the
same as using --disable-threads.
NOTE: If combined with --enable-small, the
resulting liblzma won't be thread safe,
that is, if a multi-threaded application
calls any liblzma functions from more than
one thread, something bad may happen.
--enable-symbol-versions --enable-symbol-versions
Use symbol versioning for liblzma. This is enabled by Use symbol versioning for liblzma. This is enabled by
default on GNU/Linux, other GNU-based systems, and default on GNU/Linux, other GNU-based systems, and
FreeBSD. FreeBSD.
--enable-debug --enable-debug
This enables the assert() macro and possibly some other This enables the assert() macro and possibly some other
run-time consistency checks. It makes the code slower, so run-time consistency checks. It makes the code slower, so
you normally don't want to have this enabled. you normally don't want to have this enabled.
skipping to change at line 379 skipping to change at line 411
--------------------------- ---------------------------
3.1. Dependencies 3.1. Dependencies
POSIX shell (sh) and bunch of other standard POSIX tools are required POSIX shell (sh) and bunch of other standard POSIX tools are required
to run the scripts. The configure script tries to find a POSIX 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 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 gl_cv_posix_shell=/path/to/posix-sh as an argument to the configure
script. script.
Some of the scripts require also mktemp. The original mktemp can be xzdiff (xzcmp/lzdiff/lzcmp) may use mktemp if it is available. As
found from <http://www.mktemp.org/>. On GNU, most will use the mktemp a fallback xzdiff will use mkdir to securely create a temporary
program from GNU coreutils instead of the original implementation. directory. Having mktemp available is still recommended since the
Both mktemp versions are fine for XZ Utils (and practically for mkdir fallback method isn't as robust as mktemp is. The original
everything else too). 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.
In addition to using xz to decompress .xz files, xzgrep and xzdiff
use gzip, bzip2, and lzop to support .gz, bz2, and .lzo files.
3.2. PATH 3.2. PATH
The scripts assume that the required tools (standard POSIX utilities, The scripts assume that the required tools (standard POSIX utilities,
mktemp, and xz) are in PATH; the scripts don't set the PATH themselves. 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 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 latter group can easily patch the scripts before running the configure
script by taking advantage of a placeholder line in the scripts. script by taking advantage of a placeholder line in the scripts.
For example, to make the scripts prefix /usr/bin:/bin to PATH: For example, to make the scripts prefix /usr/bin:/bin to PATH:
skipping to change at line 449 skipping to change at line 486
4.4. Lots of warnings about symbol visibility 4.4. Lots of warnings about symbol visibility
On some systems where symbol visibility isn't supported, GCC may On some systems where symbol visibility isn't supported, GCC may
still accept the visibility options and attributes, which will make still accept the visibility options and attributes, which will make
configure think that visibility is supported. This will result in configure think that visibility is supported. This will result in
many compiler warnings. You can avoid the warnings by forcing the many compiler warnings. You can avoid the warnings by forcing the
visibility support off by passing gl_cv_cc_visibility=no as an visibility support off by passing gl_cv_cc_visibility=no as an
argument to the configure script. This has no effect on the argument to the configure script. This has no effect on the
resulting binaries, but fewer warnings looks nicer and may allow resulting binaries, but fewer warnings looks nicer and may allow
using --enable-werror. using --enable-werror.
4.5. "make check" fails
If the other tests pass but test_scripts.sh fails, then the problem
is in the scripts in src/scripts. Comparing the contents of
tests/xzgrep_test_output to tests/xzgrep_expected_output might
give a good idea about problems in xzgrep. One possibility is that
some tools are missing from the current PATH or the tools lack
support for some POSIX features. This can happen at least on
Solaris where the tools in /bin may be ancient but good enough
tools are available in /usr/xpg4/bin or /usr/xpg6/bin. One fix
for this problem is described in section 3.2 of this file.
If tests other than test_scripts.sh fail, a likely reason is that
libtool links the test programs against an installed version of
liblzma instead of the version that was just built. This is
obviously a bug which seems to happen on some platforms.
A workaround is to uninstall the old liblzma versions first.
If the problem isn't any of those described above, then it's likely
a bug in XZ Utils or in the compiler. See the platform-specific
notes in this file for possible known problems. Please report
a bug if you cannot solve the problem. See README for contact
information.
4.6. liblzma.so (or similar) not found when running xz
If you installed the package with "make install" and get an error
about liblzma.so (or a similarly named file) being missing, try
running "ldconfig" to update the run-time linker cache (if your
operating system has such a command).
 End of changes. 7 change blocks. 
21 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/