libc ..(3264)
-
[ zlib ..(-32-)
] -
gtk2 ..(-64-)
-
The zlib library is usually compiled as a 32bit-off_t library. That is due to the fact that zlib does not use a proper autoconfiguration script but only a minimal compile wrapper - according to the website that is actually intentional. With respect to 64on32 however it results that the library is compiled with the local compilation defaults, and in the linux/solaris case that is 32bit-off_t.
Most of the calls are not problematic however, there are only three of them that one should be wary about:
ZEXTERN z_off_t ZEXPORT gzseek OF((gzFile file, z_off_t offset, int whence)); ZEXTERN z_off_t ZEXPORT gztell OF((gzFile file)); ZEXTERN gzFile ZEXPORT gzdopen OF((int fd, const char *mode));
The first two of them can make for a nice and pretty callframe-mismatch while the latter is subject to filedescriptor-inheritance problems. A usual linux system will have dozens of binaries and libraries linked with this 32bit-off_t library. As long none of these three is used it is quite improbable that problems will come up too soon. Still, the testscript presented on this site will warn at any dependency where a 64bit-off_t binary links with the 32bit-off_t zlib library.
Among spurious problems from above, users might notice another
constraint coming from the fact that libz is compiled as 32bit-off_t:
that's simply for functions like gzopen()
which will
make a file to be opened in compatibility mode on a Unix98 system.
That will not allow it to be enlarged beyond the 2GiB barrier that
is imposed by 32bit-off_t. That is surely unexpected to most.
Therefore, a bug report was filed to zlib-at-gzip-org, but there was no response in the few time that has passed till now (which is 13-01-2003). It may be that the linux distro makers do get aware earlier of the problem space and modify the packaging script to compile zlib as a largefile library. That makes much sense, and it would not hurt anywhere - the three problematic cases of above just shift sides but not place.