[Zlib-devel] [PATCH] Avoid testing _LARGEFILE_64_SOURCE and _FILE_OFFSET_BITS directly

[Mark Adler]

On Mar 26, 2010, at 12:04 PM, Xin LI wrote:
> Unfortunately some third party programs defines _LARGEFILE_64_SOURCE
> when compiling on FreeBSD as a workaround, as reported by some Gentoo
> developers.

They should be using _FILE_OFFSET_BITS instead of _LARGEFILE64_SOURCE, but I will look into a workaround for their workaround.

> The proposed change make zlib more platform neutral.

Unfortunately the proposed changes break the LFS functionality.

On Mar 26, 2010, at 12:59 PM, Xin LI wrote:
> Or perhaps during zlib's ./configure?  I think once zlib binary has
> been built, the zlib.h (zconf.h actually) installed together with it
> should be somewhat "fixed configuration" instead of depending system
> headers or arbitrary user-defined macros.

No, the intent is in fact for the library functions to depend on the macro definitions, per the Large File Summit document.  The point is to maintain binary compatibility with previous versions of the library by providing functions that link correctly using 32-bit offsets, yet provide functions that use 64-bit offsets on request.  This duplicates the behavior of stdio on such systems.

On Mar 26, 2010, at 1:36 PM, Xin LI wrote:
> What will happen if, say, zlib is compiled on one of these platforms
> without _FILE_OFFSET_BITS defined, and a program happens to compile
> with _FILE_OFFSET_BITS == 64?  I th

Only good things will happen.  zlib is always compiled without _FILE_OFFSET_BITS defined.  _FILE_OFFSET_BITS is only used by an application.  It requests an off_t size.  An application that defines _FILE_OFFSET_BITS=64 then gets the zlib functions with the standard names using 64-bit offsets, where the off_t type is then defined to be 64 bits.  This behavior is how stdio behaves on those systems.

Mark