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

[Xin LI]

Hi, Mark,

On Fri, Mar 26, 2010 at 12:32 PM, Mark Brown <broonie at sirena.org.uk> wrote:
> On Fri, Mar 26, 2010 at 12:04:26PM -0700, Xin LI wrote:
>
>> Here is a patch that avoids testing _LARGEFILE_64_SOURCE and
>> _FILE_OFFSET_BITS directly in zlib.h.
>
> Your MUA appears to have encoded this as a binary file which isn't
> helpful for quoting - you might want to look at your MUA configuration.
> Anyway...

I have put a copy of the patch here for your convenience:

http://people.freebsd.org/~delphij/for_review/zlib-namespace.diff

>
>> *BSDs (including Mac OS X) have 64-bit off_t from the day 1 as
>> inherited from BSD Unix as I have verified from 44BSD's SCCS tree (the
>> original change happened in revision 7.21 92/05/13 14:44:26 by
>> mckusick).  Also, _LARGEFILE_64_SOURCE doesn't apply to us and
>> _FILE_OFFSET_BITS is not defined on these platforms.
>
> _FILE_OFFSET_BITS is not defined by the platform.  This is something
> that can be defined during compilation to force off_t to be whatever the
> value is, boiling down to a noop if off_t is 64 bit anyway.

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.

Note that _FILE_OFFSET_BITS nor _LARGEFILE_64_SOURCE are part of LFS
and is not supposed to appear on any operating systems other than
Linux, thus, portable programs should not depend on these macros
unconditionally IMHO.

> If we're going to do a bodge here it should also be done on 64 bit
> architectures in general since they will generally have started off with
> 64 bit off_t too.
>
>> Unfortunately some third party programs defines _LARGEFILE_64_SOURCE
>> when compiling on FreeBSD as a workaround, as reported by some Gentoo
>> developers.  This would break zlib.h definations since zlib uses
>> _LARGEFILE_64_SOURCE as an indicator of availability of *64 functions.
>
> That's exactly what _LARGEFILE64_SOURCE means - it's a request to define
> the extra 64 bit variants of the APIs.  zlib simply follows suit and
> adds its own into the mix.  If it doesn't make those APIs available then
> presumably these programs are just plain broken on the affected platforms
> anyway since the underlying 64 bit I/O functions aren't available and
> therefore can't be built and linked against.  Given that it's not clear
> that ignoring it is ever the most sensible solution.
>
>> The proposed change make zlib more platform neutral.  It introduces
>> two namespaced macros: ZLIB_FILE_OFFSET_BITS and
>> ZLIB_LARGEFILE_64_SOURCE.  For *BSD and Mac OS X,
>> ZLIB_FILE_OFFSET_BITS would be defined as 64; for non-BSD platforms,
>> ZLIB_FILE_OFFSET_BITS would be dependent of _FILE_OFFSET_BITS.
>> used by third parties).
>
> TBH I'm really surprised any of the programs that trigger issues (what
> exactly are the issues?) here ever work.

I'm still waiting the FreeBSD's package build cluster to give me some
further build error logs.  Currently I am aware that cups-client and
print/cups-image were broken.

Cheers,
-- 
Xin LI <delphij at delphij.net> http://www.delphij.net