Re: [RFC] Reduce namespace pollution on zlib.h
Xin LI delp...@gmail.com writes: I will merge an upstream change from zlib, which basically unexpose LFS stuff on FreeBSD, and I plan to keep the off_t bits == 64. However, I would highly recommend ports maintainers to push upstream fix for LFS64 definition removal since they are wrong on FreeBSD LFS64 is not correct on Linux either; just #define _FILE_OFFSET_BITS 64 before #include sys/stat.h and use struct stat / stat() as usual. The AC_SYS_LARGEFILE autoconf macro takes care of that for you, provided you remember to #include config.h in your code. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] Reduce namespace pollution on zlib.h
On 2010-Mar-27, 02:51, Dag-Erling Smørgrav wrote: Xin LI delp...@delphij.net writes: So... May I consider my import just exposed some existing bugs in other applications and we don't want to workaround these issues? Correct. Just to make it clear so that everyone knows how we're going to handle this: are you (src people) going to commit a fix to unexpose LFS crap or are we (ports people) supposed to fix each and every single port that supposes to be on Linux? The attentive reader will note a bias towards the former :) -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpBDuTIcSGH3.pgp Description: PGP signature
Re: [RFC] Reduce namespace pollution on zlib.h
I will merge an upstream change from zlib, which basically unexpose LFS stuff on FreeBSD, and I plan to keep the off_t bits == 64. However, I would highly recommend ports maintainers to push upstream fix for LFS64 definition removal since they are wrong on FreeBSD On Mar 31, 2010 3:30 AM, Pietro Cerutti g...@gahr.ch wrote: On 2010-Mar-27, 02:51, Dag-Erling Smørgrav wrote: Xin LI delp...@delphij.net writes: So... ... Just to make it clear so that everyone knows how we're going to handle this: are you (src people) going to commit a fix to unexpose LFS crap or are we (ports people) supposed to fix each and every single port that supposes to be on Linux? The attentive reader will note a bias towards the former :) -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] Reduce namespace pollution on zlib.h
On 2010-Mar-31, 03:41, Xin LI wrote: I will merge an upstream change from zlib, which basically unexpose LFS stuff on FreeBSD, and I plan to keep the off_t bits == 64. However, I would highly recommend ports maintainers to push upstream fix for LFS64 definition removal since they are wrong on FreeBSD Sounds great, thanks! On Mar 31, 2010 3:30 AM, Pietro Cerutti g...@gahr.ch wrote: On 2010-Mar-27, 02:51, Dag-Erling Smørgrav wrote: Xin LI delp...@delphij.net writes: So... ... Just to make it clear so that everyone knows how we're going to handle this: are you (src people) going to commit a fix to unexpose LFS crap or are we (ports people) supposed to fix each and every single port that supposes to be on Linux? The attentive reader will note a bias towards the former :) -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpbtgmgIxofi.pgp Description: PGP signature
Re: [RFC] Reduce namespace pollution on zlib.h
On Fri, Mar 26, 2010 at 05:26:03PM -0700, Xin LI wrote: 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 :( To keep ports code untouched you should not #undef anything like that names in the public zlib.h header, just remove/redefine *LARGEFILE* for zlib only in some private internal header. -- http://ache.pp.ru/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[RFC] Reduce namespace pollution on zlib.h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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? Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLrP4XAAoJEATO+BI/yjfBk2YH/Ag38kdtjxAk0l2kdgnHPnZ7 Wf9uk+0ixgE8X2uHfkOeiVO99Ma47aFU/thS1qgXRIWqP/iQEMqOiUayubYnsCJk K8quwzEuifM0hlIPzHxgzo5/e1O6GhUdIkJVJj+T//twG2BGXziYHMye/aph0iRa kW5DEq469jBoz62N8FDn4iatZoXT5boBc0bE3GQCKJhUADbpC84vjCCHfdVx50mu x5hEO88TNaWSn4AkPgs0xPBYQNM+w6t2g/CLNfylumIUVHcSs+v8sLKrxdqqvKNx hn97KmDagy5BVaWaAFAqFclgfAVbjfa8NIaOr8egxnuVHXTzEzjHFUD7fS22Oqo= =eOpg -END PGP SIGNATURE- Index: lib/libz/zconf.h === --- lib/libz/zconf.h(revision 205651) +++ lib/libz/zconf.h(working copy) @@ -375,6 +375,13 @@ # endif #endif +#if defined(__FreeBSD__) defined(_LARGEFILE64_SOURCE) +#if !defined(__FreeBSD_LARGEFILE64_SOURCE) +#define __FreeBSD_LARGEFILE64_SOURCE +#endif +#undef _LARGEFILE64_SOURCE +#endif + #ifdef _LARGEFILE64_SOURCE # include sys/types.h #endif @@ -391,6 +398,9 @@ #include sys/types.h #definez_off_t off_t #ifndef _FILE_OFFSET_BITS +#if !defined(__FreeBSD_FILE_OFFSET_BITS) +#define __FreeBSD_FILE_OFFSET_BITS +#endif #define _FILE_OFFSET_BITS 64 #endif Index: lib/libz/zlib.h === --- lib/libz/zlib.h (revision 205651) +++ lib/libz/zlib.h (working copy) @@ -1597,6 +1597,20 @@ ZEXTERN const uLongf * ZEXPORT get_crc_tableOF((void)); ZEXTERN intZEXPORT inflateUndermine OF((z_streamp, int)); +#if defined(__FreeBSD_LARGEFILE64_SOURCE) +#undef __FreeBSD_LARGEFILE64_SOURCE +#if !defined(_LARGEFILE64_SOURCE) +#define _LARGEFILE64_SOURCE +#endif +#endif + +#if defined(__FreeBSD_FILE_OFFSET_BITS) +#undef __FreeBSD_FILE_OFFSET_BITS +#if defined(_FILE_OFFSET_BITS) +#undef _FILE_OFFSET_BITS +#endif +#endif + #ifdef __cplusplus } #endif ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] Reduce namespace pollution on zlib.h
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] Reduce namespace pollution on zlib.h
Xin LI delp...@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 - d...@des.no ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] Reduce namespace pollution on zlib.h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/03/26 17:02, Dag-Erling Smørgrav wrote: Xin LI delp...@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 delp...@delphij.nethttp://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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] Reduce namespace pollution on zlib.h
Xin LI delp...@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 - d...@des.no ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] Reduce namespace pollution on zlib.h
Xin LI delp...@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 - d...@des.no ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] Reduce namespace pollution on zlib.h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/03/26 17:46, Dag-Erling Smørgrav wrote: Xin LI delp...@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(). So... May I consider my import just exposed some existing bugs in other applications and we don't want to workaround these issues? I'm sort of feeling guilty for making the transition path hard, though... Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLrWLPAAoJEATO+BI/yjfBJAcH/0WLPx5wiV/5ue4ZmmdPojMi bxK0XneEwO56bJMOJHg6qxBqwwBm3egabq1abkRYLdOVwoXc9hiGAdVJjjymJ3lz xJWV23XpLHzso9z3Ev33virj32+Br++zsucdh5aEmC0YvdpvFDQUiU9LUNIErf/g bjqzrapugiEkrL8xD2Maq5F+OdeMPOV3HXMjU39RpyRKVTfIkG4tfL8wDmBD/KAI 7byS1syUqDP2uvIvHmO2R3lFrto6cjwRhn38Y51XOQpu/Wvrp6KEKX47/vFBUjwE JHPIGlbkoo3LezPjE+Sv6I4+MAsNncmyol5jKGAxmfe9wNjkHs3Br/AyPGbNCyI= =00ta -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] Reduce namespace pollution on zlib.h
Xin LI delp...@delphij.net writes: So... May I consider my import just exposed some existing bugs in other applications and we don't want to workaround these issues? Correct. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
