Using optimized byte swaps reduced portability for no real benefit,
since they are in parts of the code that represent a tiny fraction
of the execution time. So a simple definition of a byte swap is
now used.
SunOS 4.1 claims that it is __STDC__, but it does not have strerror
in string.h. Instead of using __STDC__, this puts a direct test
for strerror in configure, and uses that information in gzguts.h.
SunOS 4.1 doesn't have memmove(), and there may be others. memcpy()
should not be used for overlapping copies, so here a simple copy is
implemented that works for the particular direction of the overlap,
which is where the destination precedes the source.
Apple removed support for gcov in the default gcc compiler chain,
when they moved to llvm. This can be circumvented in XCode 4.2 by
using the gcc chain with gcc-4.2. This patch allows setting
GCC_CLASSIC to the name of a real gcc executable (e.g. "gcc-4.2")
to allow coverage testing.
crc32.c was #including limits.h in order to find a four-byte integer
type. It was doing this even if Z_SOLO were defined, violating the
intent of Z_SOLO, which is to include no library headers and require
no library functions. Now crc32.c obeys the intent of Z_SOLO, but
with the downside that crc32() will be slower than when not compiled
with Z_SOLO. This can be remedied manually by typedefing u4 to a
known four-byte unsigned integer type, and #defining BYFOUR in
crc32.c.
gzflags() was put in gzwrite.c in order to be compiled exactly the
same as gzprintf(), so that it was guaranteed to return the correct
information. However that causes a static linkage to zlib to bring
in many routines that are often not used. All that is required to
duplicate the compilation environment of gzprintf() is to include
gzguts.h. So that is now done in zutil.c to assure that the correct
flags are returned.
When successful, gzputc would return the second argument. If the
second argument were -1, gzputc would return -1 instead of the
character written, which was 255. However the -1 would not be
distinguishable from an error. Now gzputc returns 255 in that
case.
This makes build-testing and installing the minizip/miniunzip programs
as simple as "autoreconf -if && ./configure --enable-demos && make &&
make install". Without --enable-demos, the makefile will only build
and install the library, as before. Helped by Mike Frysinger.
minizip/miniunzip were not intended to be general-purpose installed
utilities, but they can be useful from time to time as a lightweight
substitute for zip/unzip. You can also use them to quickly test that
the library installation procedure worked.
Instead of using relative paths directly, use paths relative to
top_srcdir and top_builddir to refer to source files and built files,
respectively.
Note that the toplevel zlib configure script still does not have any
special support for out-of-tree builds. But now you can do
(cd contrib/minizip && autoreconf -fis)
mkdir -p BUILD/test
cp *.c *.h *.in zlib.map configure zlib.3 BUILD
cp test/*.c BUILD/test
(cd BUILD && ./configure --shared)
(cd BUILD && make)
mkdir -p BUILD/contrib/minizip
cd BUILD/contrib/minizip
../../../contrib/minizip/configure
make
While at it, move the include path and library path settings to
CPPFLAGS and LDFLAGS respectively instead of setting both in CFLAGS.
Thanks to Mike Frysinger for advice.
Trying to build the minizip utility from contrib/minizip after an
autoreconf -f:
libtool: link: gcc -g -O2 -o minizip minizip.o
minizip.o: In function `getFileCrc':
/tmp/zlib/contrib/minizip/minizip.c:211: undefined reference to `crc32'
minizip.o: In function `main':
/tmp/zlib/contrib/minizip/minizip.c:378: undefined reference to `zipOpen64'
/tmp/zlib/contrib/minizip/minizip.c:451: undefined reference to `zipOpenNewFileInZip3_64'
/tmp/zlib/contrib/minizip/minizip.c:502: undefined reference to `zipCloseFileInZip'
/tmp/zlib/contrib/minizip/minizip.c:509: undefined reference to `zipClose'
/tmp/zlib/contrib/minizip/minizip.c:485: undefined reference to `zipWriteInFileInZip'
collect2: error: ld returned 1 exit status
The cause: contrib/minizip/Makefile.am does not specify that minizip
needs to be linked to libminizip. With some linkers (e.g., GNU
binutils without --copy-dt-needed-entries), an indirect dependency
cannot be used to resolve symbols, so link to libz for crc32(), too.
Trying to build miniunzip utility from contrib/minizip after an
autoreconf -f produces
[...]
In file included from minizip.c:61:0:
zip.h:50:18: fatal error: zlib.h: No such file or directory
unless zlib is already installed. Use AM_CFLAGS to set the include
path and library path to point to the just-build copy of zlib to
fix this. (This was already done for libminizip but not the binaries
that use it before this patch.)
Mark Adler