Reduce namespace pollution on zlib.h
in [Ports]
|
Prev: default binutils - linker 2.15 versus 2.20
Next: cvs commit: ports/japanese/esecanna Makefileports/japanese/esecanna/files esecanna.in esecanna.sh
From: Jung-uk Kim on 26 Mar 2010 17:35 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 _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= on 26 Mar 2010 20:02 Xin LI <delphij(a)delphij.net> writes: > 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. This is wrong, FreeBSD has native 64-bit stat() etc. and does not need _LARGEFILE_WHATEVER. DES -- Dag-Erling Smørgrav - des(a)des.no _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Xin LI on 26 Mar 2010 20:26 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010/03/26 17:02, Dag-Erling Smørgrav wrote: > Xin LI <delphij(a)delphij.net> writes: >> 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. > > This is wrong, FreeBSD has native 64-bit stat() etc. and does not need > _LARGEFILE_WHATEVER. Yes we do not need that and it just cause compilation errors. The problem is that some third party software thinks that they need to define _LARGEFILE64_*, which will break zlib.h on FreeBSD :( I'm inclined to adopt a solution similar to what Apple (pointed out by Jkim@) is currently having by disabling the _LARGEFILE64_SOURCE if __FreeBSD__ is defined. Cheers, - -- Xin LI <delphij(a)delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLrVCbAAoJEATO+BI/yjfBj4AIAMcUAjLIZpNW2sGD0/Z9XLU3 SBevqjvR9iwGANTXOKiB3aofvUygmTfG+8KrxlZTJ51O8vlYgA28eGT0iiDpfoLz yUtpAN1MIitPp/VtNwHpTpfJcfP+AX060G4MGdxUWCHjoJWhbWMv7OnLbquGdglZ 8bbvQR9EDxm8gM2OT9/b14WOsilYwFBpNlNvxl+Q9d0oWNIi08xWmwvC2aWF7L/6 oTFp2tCKXfi++RCxPU5v+q5SaogKjx1bw612UWvetEhHylcXQpQxqjtyL5WA5IAd bRYJquOjt3+3mziE0VLlQSQgUSCSYMXls6LqmQSfe3W1sU7wG1rFlZG5BfD/UyM= =DDry -----END PGP SIGNATURE----- _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= on 26 Mar 2010 20:46 Xin LI <delphij(a)delphij.net> writes: > The problem is that some third party software thinks that they need to > define _LARGEFILE64_*, which will break zlib.h on FreeBSD :( Then that third-party software is broken and needs to be fixed. _LARGEFILE64_SOURCE is (supposed to be) used to expose the stat64() API. FreeBSD does not have stat64(). Any application that defines it and then calls stat() instead of stat64() is broken to begin with. Any application that defines it and then calls stat64() will not compile on FreeBSD. See sections 3.3.2 and 3.1 of this document: http://www.unix.org/version2/whatsnew/lfs20mar.html On Linux, it's a no-op, because while the kernel has separate 32-bit stat() and 64-bit stat64() syscalls, glibc aliases stat() to stat64(). DES -- Dag-Erling Smørgrav - des(a)des.no _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= on 26 Mar 2010 20:49
Xin LI <delphij(a)delphij.net> writes: > The recent zlib import has added some assumption that > _LARGEFILE_64_SOURCE is only defined on systems with System V style > *64 interface. I forgot to address this point in your original message. Basically, the entire thread boils down to this: that assumption is correct. DES -- Dag-Erling Smørgrav - des(a)des.no _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org" |