bzip2 [ Home | Documentation | Downloads ]
4.2. Portability issues

4.2. Portability issues

After some consideration, I have decided not to use GNU autoconf to configure 0.9.5 or 1.0.

autoconf, admirable and wonderful though it is, mainly assists with portability problems between Unix-like platforms. But bzip2 doesn't have much in the way of portability problems on Unix; most of the difficulties appear when porting to the Mac, or to Microsoft's operating systems. autoconf doesn't help in those cases, and brings in a whole load of new complexity.

Most people should be able to compile the library and program under Unix straight out-of-the-box, so to speak, especially if you have a version of GNU C available.

There are a couple of __inline__ directives in the code. GNU C (gcc) should be able to handle them. If you're not using GNU C, your C compiler shouldn't see them at all. If your compiler does, for some reason, see them and doesn't like them, just #define __inline__ to be /* */. One easy way to do this is to compile with the flag -D__inline__=, which should be understood by most Unix compilers.

If you still have difficulties, try compiling with the macro BZ_STRICT_ANSI defined. This should enable you to build the library in a strictly ANSI compliant environment. Building the program itself like this is dangerous and not supported, since you remove bzip2's checks against compressing directories, symbolic links, devices, and other not-really-a-file entities. This could cause filesystem corruption!

One other thing: if you create a bzip2 binary for public distribution, please consider linking it statically (gcc -static). This avoids all sorts of library-version issues that others may encounter later on.

If you build bzip2 on Win32, you must set BZ_UNIX to 0 and BZ_LCCWIN32 to 1, in the file bzip2.c, before compiling. Otherwise the resulting binary won't work correctly.

Copyright © 1996 - 2014