Date: Fri, 26 Mar 2010 17:35:52 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-arch@FreeBSD.org, d@delphij.net Cc: ports@freebsd.org, the_paya@gentoo.org, Alexander Logvinov <avl@logvinov.com> Subject: Re: [RFC] Reduce namespace pollution on zlib.h Message-ID: <201003261735.56279.jkim@FreeBSD.org> In-Reply-To: <4BACFE18.7010309@delphij.net> References: <4BACFE18.7010309@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 26 March 2010 02:34 pm, Xin LI wrote: > Hi, > > 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... http://www.gnu.org/s/libc/manual/html_node/Feature-Test-Macros.html 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 ? ? ? [1] 4 N Y Y 8 ? ? ? [1] 5 Y N N 4 ? ? ? [2] 6 Y N Y 8 N Y N [3] 7 Y Y N 4 Y Y Y [4] 8 Y Y Y 8 Y Y Y [5] 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) [1] Impossible. Some people argue that _LARGEFILE64_SOURCE must imply _LARGEFILE_SOURCE. [2] Impossible. Some people argue that _LARGEFILE_SOURCE must imply _LARGEFILE64_SOURCE and/or _FILE_OFFSET_BITS=64. [3] All BSDs (including Darwin) and the future of Linux. ;-) [4] Transitional according to the GNU libc manual. [5] 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: http://trac.macports.org/changeset/65036 Basically _LARGEFILE64_SOURCE is completely unnecessary and evil for all BSDs. > This unfortunately could cause some namespace pollution. As such, > I would propose the attached changes to zlib headers: > > zconf.h: > * If _LARGEFILE_64_SOURCE is defined, set > __FreeBSD_LARGEFILE_64_SOURCE and undefine it, as it would break > zlib.h > * If _FILE_OFFSET_BITS is undefined, set > __FreeBSD_FILE_OFFSET_BITS and define it as 64. > > zlib.h: > * 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: http://trac.macports.org/changeset/64855 It seems the author of zlib suggested it is better solution, actually: http://trac.macports.org/ticket/24061 FYI, there is a web site dedicated for this issue: http://ac-archive.sourceforge.net/largefile/index.html Yes, I had to google a lot last night... :-( Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003261735.56279.jkim>