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: Xin LI on 26 Mar 2010 21:43 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010/03/26 17:46, Dag-Erling Smørgrav wrote: > 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(). 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 <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) 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(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 21:51 Xin LI <delphij(a)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 - 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 31 Mar 2010 07:24
Xin LI <delphij(a)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 - 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" |