[RFC] Reduce namespace pollution on zlib.h
jkim at FreeBSD.org
Fri Mar 26 21:36:07 UTC 2010
On Friday 26 March 2010 02:34 pm, Xin LI wrote:
> The recent zlib import has added some assumption that
> _LARGEFILE_64_SOURCE is only defined on systems with System V style
> *64 interface. Moreover, I have added _FILE_OFFSET_BITS = 64
> definition into zconf.h so that it would pick up the 64 bit
> interface properly.
I guess you meant _LARGEFILE64_SOURCE. :-)
Last night I had so much trouble rebuilding ports because many ports
have bogus assumption that _LARGEFILE64_SOURCE is required for
supporting large files. It seems _LARGEFILE64_SOURCE is only needed
for OSes where sizeof(off_t) is 4 and it provides additional
functions such as fseeko64() and ftello64(), which takes off64_t type
as an argument or returns off64_t type. However, _FILE_OFFSET_BITS =
64 means sizeof(off_t) is 8 but you have to avoid off64_t, fseeko46
(), ftello64(), etc, etc...
If I read them all correctly, it means (on 32-bit platforms):
Case M1 M2 M3 T1 T2 F1 F2 Note
1 N N N 4 N N N
2 N N Y 8 N N N
3 N Y N 4 ? ? ? 
4 N Y Y 8 ? ? ? 
5 Y N N 4 ? ? ? 
6 Y N Y 8 N Y N 
7 Y Y N 4 Y Y Y 
8 Y Y Y 8 Y Y Y 
M1: _LARGEFILE_SOURCE (N: undefined, Y: defined)
M2: _LARGEFILE64_SOURCE (N: undefined, Y: defined)
M3: _FILE_OFFSET_BITS (N: undefined or 32, Y: 64)
T1: off_t (4: 32-bit, 8: 64-bit)
T2: off64_t (N: unavail, Y: avail)
F1: fseeko() and ftello() (N: unavail, Y: avail)
F2: fseeko64() and ftello64() (N: invisible, Y: visible)
 Impossible. Some people argue that _LARGEFILE64_SOURCE must imply
 Impossible. Some people argue that _LARGEFILE_SOURCE must imply
_LARGEFILE64_SOURCE and/or _FILE_OFFSET_BITS=64.
 All BSDs (including Darwin) and the future of Linux. ;-)
 Transitional according to the GNU libc manual.
 It is wrong but I think it exists.
So, zlib developers wanted to distinguish #6 from #7 and #8. I think
we can do something like Apple did:
Basically _LARGEFILE64_SOURCE is completely unnecessary and evil for
> This unfortunately could cause some namespace pollution. As such,
> I would propose the attached changes to zlib headers:
> * If _LARGEFILE_64_SOURCE is defined, set
> __FreeBSD_LARGEFILE_64_SOURCE and undefine it, as it would break
> * If _FILE_OFFSET_BITS is undefined, set
> __FreeBSD_FILE_OFFSET_BITS and define it as 64.
> * If __FreeBSD_LARGEFILE_64_SOURCE is defined and
> _LARGEFILE_64_SOURCE undefined, undefine
> __FreeBSD_LARGEFILE_64_SOURCE and define _LARGEFILE_64_SOURCE.
> * If __FreeBSD_FILE_OFFSET_BITS is defined and _FILE_OFFSET_BITS
> is defined, undefine both.
> This approach is kind of mess, though, but would avoid massive
> changes which I'd propose for next zlib release.
> Comments? Objections?
Please don't do that. I think we just have to fix individual ports
for now, something like this:
It seems the author of zlib suggested it is better solution, actually:
FYI, there is a web site dedicated for this issue:
Yes, I had to google a lot last night... :-(
More information about the freebsd-ports