index -summary -history -testscript perl / python problems -with callframes -with structures -largefile seeks -broken builds systems -freeBSD/darwin -linux/solaris -64on32 mix -distro makers -win32/other (2) libraries - libc ..(3264)
- zlib ..(-32-)
- gtk2 ..(-64-)
converting -old non-off_t code -going largefile -longlong default -face dualmode -make twinlibs -and defend (it) programming -largefile default -off_t in headers -make export64 -find mismatch -the autowrappers -environ changes -best practice? old library -dualmode renames -the extra function -largefile64_source -glibc headers -libgz example *** new library -dual export -largefiles win32 -compat32 calls -compat32 library -long32 dualmode links -some quotes -sitemap / mpl -large.file Group* -ac-archive Site*
(C) 2002-01-13 Guido U. Draheim |
zlib - a 32bit off_tThe 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 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. |