Xin LI 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
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
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
On 2010-Mar-27, 02:51, Dag-Erling Smørgrav wrote:
> Xin LI 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:
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
Xin LI 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://
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2010/03/26 17:46, Dag-Erling Smørgrav wrote:
> Xin LI 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 an
Xin LI 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
Xin LI 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2010/03/26 17:02, Dag-Erling Smørgrav wrote:
> Xin LI 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_BIT
Xin LI 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 wr
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 th
-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 int
13 matches
Mail list logo
