From owner-freebsd-ports@FreeBSD.ORG Fri Mar 26 21:36:06 2010 Return-Path: Delivered-To: ports@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 4899D106566B; Fri, 26 Mar 2010 21:36:06 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-arch@FreeBSD.org, d@delphij.net Date: Fri, 26 Mar 2010 17:35:52 -0400 User-Agent: KMail/1.6.2 References: <4BACFE18.7010309@delphij.net> In-Reply-To: <4BACFE18.7010309@delphij.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003261735.56279.jkim@FreeBSD.org> Cc: ports@freebsd.org, the_paya@gentoo.org, Alexander Logvinov Subject: Re: [RFC] Reduce namespace pollution on zlib.h X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 21:36:07 -0000 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