Doug Barton wrote:
On 03/26/10 14:03, Steven Kreuzer wrote:
So, it seems like most of the time python scripts will work with HUGE_STACK_SIZE
turned off, but every once and a while some scripts will fail in non obvious
ways
that could leave a person scratching their head for weeks trying to get
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
On Sat, Mar 27, 2010 at 12:21 AM, CeDeROM wrote:
> On Fri, Mar 26, 2010 at 7:19 AM, Rene Ladan wrote:
>> 2010/3/26 CeDeROM :
>>> Hello world!
>>>
>>> I have problems building applications requiring ld 2.20 (located at
>>> /usr/local/bin) where ld 2.15 (located at /usr/bin) is being invoked
>>> wi
net-mgmt/trafd, which was previously failing is OK after this commit.
Thanks for fixing it!
A description of the testing process can be found here:
http://T32.TecNik93.com/FreeBSD/QA-Tindy/
Thanks for your work on making FreeBSD better,
--
QAT - your friendly neighborhood Daemon,
preparing a
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
japanese/esecanna, which was previously failing is OK after this commit.
Thanks for fixing it!
A description of the testing process can be found here:
http://T32.TecNik93.com/FreeBSD/QA-Tindy/
Thanks for your work on making FreeBSD better,
--
QAT - your friendly neighborhood Daemon,
preparing
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
The Restless Daemon identified a PLIST error while trying to build:
trafd-3.0.2.1_1 maintained by po...@freebsd.org
Makefile ident: $FreeBSD: ports/net-mgmt/trafd/Makefile,v 1.19 2010/03/27
00:42:06 dougb Exp $
Excerpt from http://QAT.TecNik93.com/logs/8-STABLE-NPD/trafd-3.0.2.1_1.log :
instal
The Restless Daemon identified a PLIST error while trying to build:
ja-esecanna-1.0.1_5 maintained by po...@freebsd.org
Makefile ident: $FreeBSD: ports/japanese/esecanna/Makefile,v 1.34 2010/03/27
00:33:31 dougb Exp $
Excerpt from http://QAT.TecNik93.com/logs/8-STABLE-NPD/ja-esecanna-1.0.1_5.lo
-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
On Fri, Mar 26, 2010 at 7:19 AM, Rene Ladan wrote:
> 2010/3/26 CeDeROM :
>> Hello world!
>>
>> I have problems building applications requiring ld 2.20 (located at
>> /usr/local/bin) where ld 2.15 (located at /usr/bin) is being invoked
>> with c++ (gcc4.2.1). Why there are two linkers on the system
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 03/26/10 14:03, Steven Kreuzer wrote:
> So, it seems like most of the time python scripts will work with
> HUGE_STACK_SIZE
> turned off, but every once and a while some scripts will fail in non obvious
> ways
> that could leave a person scratching their head for weeks trying to get to
> the b
On Fri, Mar 26, 2010 at 3:03 PM, Steven Kreuzer wrote:
> To me, it seems like the best behavior would be to default to compiling
> with that set. I'll create
> a patch over the weekend and open a PR
>
Django and twisted don't need it. If the only app which does is zope,
defaulting to on seems to
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
On Mar 25, 2010, at 1:07 AM, Adam Vande More wrote:
> On Wed, Mar 24, 2010 at 5:50 PM, Chuck Swiger wrote:
>
>>
>> I've run and written quite a bit of Python (including Trac, Mailman, the
>> Python IDE, our own custom stuff [like some log munging and web processing
>> stuff], and even a few gr
-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
Hi,
I've improved the startup script for net/ucarp by adding multiple VHID
support, and FIB support.
Now, you can have this example of rc.conf configuration with net/ucarp
(up to the 255 VHID):
# uCarp
ucarp_enable="YES"
#ucarp_VHID_option="value"
ucarp_1_if="ed1"
ucarp_1_src="10.0.1.2"
ucarp_1_a
On Wed, 24 Mar 2010 13:02:50 -0700
Xin LI wrote:
> > So my question to maintainer now, is it going to be updated to newest
> > svn version soon or do people have to wait until it will hit stable ??
>
I don't have much time for it currently. I'll try to update as soon as
I have some time availa
2010/3/26 CeDeROM :
> Hello world!
>
> I have problems building applications requiring ld 2.20 (located at
> /usr/local/bin) where ld 2.15 (located at /usr/bin) is being invoked
> with c++ (gcc4.2.1). Why there are two linkers on the system? Is it
> possible to update the default linker to version
21 matches
Mail list logo
