Re: default binutils - linker 2.15 versus 2.20
2010/3/26 CeDeROM tomek.ce...@gmail.com: 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 2.20? An upgrade is not possible because binutils switched to GPL3 after version 2.17 and GLP3 code is not allowed in the base system. One possible solution would be to tell the applications to use /usr/local/bin/ld explicitly. Rene -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) ___ 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: Enlightenment build failure
On Wed, 24 Mar 2010 13:02:50 -0700 Xin LI delp...@delphij.net 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 available. For now, there's a good work done by Grzegorz Blach ma...@roorback.net (ports/145008), which you can use. It's not ready to be committed into ports tree yet. -- Stanislav Sedov ST4096-RIPE pgp84FiqOULHA.pgp Description: PGP signature
net/ucarp : New rc script with multiple VHID and FIB support
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_addr=10.0.1.1 ucarp_1_shutdown=NO ucarp_3_if=ed3 ucarp_3_src=10.0.3.2 ucarp_3_pass=passcarp ucarp_3_addr=10.0.3.1 ucarp_3_fib=3 ucarp_4_if=ed4 ucarp_4_src=10.0.4.2 ucarp_4_pass=passcarp4 ucarp_4_addr=10.0.4.1 ucarp_4_fib=2 If you want to try it, you can get it here: http://bsdrp.svn.sourceforge.net/viewvc/bsdrp/trunk/Files/usr/local/etc/rc.d/ucarp I've got only one bug to solve (if someone have an idea): If ucarp is already started, and you start it again, the rc.subr should detect already running ucarp processes and prevent to launch other ucarp processes. But there is a bug somewhere, and rc.subr didn't prevent to start them again :-( Regards, Olivier ___ 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: python and HUGE_STACK_SIZE
On Mar 25, 2010, at 1:07 AM, Adam Vande More wrote: On Wed, Mar 24, 2010 at 5:50 PM, Chuck Swiger cswi...@mac.com 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 graphical Python games) without ever turning HUGE_STACK_SIZE on. I don't have any objection to turning it on, but it's not needed by default for most things. YMMV. Yes, I've had the same experience. When doing socket level python stuff, I've had to increase the buffer size, which seems to be at least indirectly related to stack size but setting it manually has been easy enough. Are there any negative repercussions to turning on huge ie like would scripts start using more memory, or is just giving them the ability to use it without explicitly setting it? 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 bottom of it 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 -- Steven Kreuzer http://www.exit2shell.com/~skreuzer ___ 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: python and HUGE_STACK_SIZE
On Fri, Mar 26, 2010 at 3:03 PM, Steven Kreuzer skreu...@exit2shell.comwrote: 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 be overkill. No offense to zope users, but I imagine freebsd zope installs aren't on every corner. It would be interesting to hear more feedback from other sources, and your coworker with the original experience. Within python, stack size(in regards to sockets) errors are made quite evident. What zope does to it I have no idea, maybe there is some abstraction going on. My main objection that I use python a lot, especially for quick network apps. One example is that I have written a python based NMS, and if every thread is going to start using more memory, then I will have to do things differently. That's okay too, but if others are doing anything similar there could be more ripples down the road. -- Adam Vande More ___ 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: python and HUGE_STACK_SIZE
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 bottom of it 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 From the discussion (not speaking from experience or python knowledge) it seems like an OPTION is the way to go, with the open question being defaults to on or defaults to off. What is the impact of HUGE_STACK_SIZE when it's compiled in, and how will it affect those running python stuff who don't actually need it? If it turns out that only a few ports need it and the impact is undesirable those ports that do need it could be adapted to test for it somehow and suggest that the user re-install python with the option. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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: cvs commit: ports/japanese/esecanna Makefile ports/japanese/esecanna/files esecanna.in esecanna.sh
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.log : these network services to be started at boot time. /usr/local/etc/rc.d/esecanna /usr/local/etc/rc.d/esecanna.sh If there are vulnerabilities in these programs there may be a security risk to the system. FreeBSD makes no guarantee about the security of ports included in the Ports Collection. Please type 'make deinstall' to deinstall the port if this is a concern. For more information, and contact details about the security status of this software, see the following webpage: http://esecanna.netfort.gr.jp/ phase 7: make package === Building package for ja-esecanna-1.0.1_5 tar: etc/rc.d/esecanna.sh: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 Creating package /tmp/packages/All/ja-esecanna-1.0.1_5.tbz Registering depends:. Creating bzip'd tar ball in '/tmp/packages/All/ja-esecanna-1.0.1_5.tbz' *** Error code 1 Stop in /a/ports/japanese/esecanna. *** Error code 1 Stop in /a/ports/japanese/esecanna. Deleting ja-esecanna-1.0.1_5 pkg_delete: file '/usr/local/etc/rc.d/esecanna.sh' doesn't exist pkg_delete: couldn't entirely delete package (perhaps the packing list is incorrectly specified?) === Checking filesystem state Deleting gmake-3.81_3 Deleting gettext-0.17_1 Deleting libiconv-1.13.1_1 === Checking filesystem state after all packages deleted build of /usr/ports/japanese/esecanna ended at Sat Mar 27 00:34:43 UTC 2010 PortsMon page for the port: http://portsmon.freebsd.org/portoverview.py?category=japaneseportname=esecanna The build which triggered this BotMail was done under tinderbox-3.3_3; dsversion: 3.2.1 on RELENG_8 on amd64, kern.smp.cpus: 8 with tinderd_flags=-nullfs -plistcheck -onceonly and ccache support, with the official up-to-date Ports Tree, with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. 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 heck of an error trapping system: - HMC and EOI? - Halt, Melt and Catch fire or Execute Operator Immediately. ___ 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: cvs commit: ports/net-mgmt/trafd Makefile ports/net-mgmt/trafd/files trafd.in trafd.sh.sample
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 : install -o root -g wheel -m 444 /work/a/ports/net-mgmt/trafd/work/trafd-3.0.2.1/traflog/traflog.format /usr/local/etc === Installing rc.d startup script(s) === Registering installation for trafd-3.0.2.1_1 === SECURITY REPORT: This port has installed the following files which may act as network servers and may therefore pose a remote security risk to the system. /usr/local/bin/trafstat This port has installed the following startup scripts which may cause these network services to be started at boot time. /usr/local/etc/rc.d/trafd /usr/local/etc/rc.d/trafd.sh.sample If there are vulnerabilities in these programs there may be a security risk to the system. FreeBSD makes no guarantee about the security of ports included in the Ports Collection. Please type 'make deinstall' to deinstall the port if this is a concern. phase 7: make package === Building package for trafd-3.0.2.1_1 tar: etc/rc.d/trafd.sh.sample: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 Creating package /tmp/packages/All/trafd-3.0.2.1_1.tbz Registering depends:. Registering conflicts: bpft-4.*. Creating bzip'd tar ball in '/tmp/packages/All/trafd-3.0.2.1_1.tbz' *** Error code 1 Stop in /a/ports/net-mgmt/trafd. Deleting trafd-3.0.2.1_1 pkg_delete: file '/usr/local/etc/rc.d/trafd.sh.sample' doesn't exist pkg_delete: couldn't entirely delete package (perhaps the packing list is incorrectly specified?) === Checking filesystem state === Checking filesystem state after all packages deleted build of /usr/ports/net-mgmt/trafd ended at Sat Mar 27 00:43:01 UTC 2010 PortsMon page for the port: http://portsmon.freebsd.org/portoverview.py?category=net-mgmtportname=trafd The build which triggered this BotMail was done under tinderbox-3.3_3; dsversion: 3.2.1 on RELENG_8 on amd64, kern.smp.cpus: 8 with tinderd_flags=-nullfs -plistcheck -onceonly and ccache support, with the official up-to-date Ports Tree, with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. 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 heck of an error trapping system: - HMC and EOI? - Halt, Melt and Catch fire or Execute Operator Immediately. ___ 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
Now OK (Re: cvs commit: ports/japanese/esecanna pkg-plist ports/net-mgmt/trafd pkg-plist)
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 a heck of an error trapping system: - HMC and EOI? - Halt, Melt and Catch fire or Execute Operator Immediately. ___ 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
Now OK (Re: cvs commit: ports/japanese/esecanna pkg-plist ports/net-mgmt/trafd pkg-plist)
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 heck of an error trapping system: - HMC and EOI? - Halt, Melt and Catch fire or Execute Operator Immediately. ___ 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: default binutils - linker 2.15 versus 2.20
On Sat, Mar 27, 2010 at 12:21 AM, CeDeROM tomek.ce...@gmail.com wrote: On Fri, Mar 26, 2010 at 7:19 AM, Rene Ladan r.c.la...@gmail.com wrote: 2010/3/26 CeDeROM tomek.ce...@gmail.com: 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 2.20? Ok, I've found few ways to accomplish this easily: -use the -B/usr/local/bin/ switch just as the -L and the -I -use environment COMPILER_PATH or better GCC_EXEC_PATH to specify path for programs executed internally by the gcc Both of these solutions simply prepends specified path before the environment data, so if the program is not found in the specified path, it is still searched in standard order :-) Testing under way.. Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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
Re: python and HUGE_STACK_SIZE
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 to the bottom of it 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 From the discussion (not speaking from experience or python knowledge) it seems like an OPTION is the way to go, with the open question being defaults to on or defaults to off. What is the impact of HUGE_STACK_SIZE when it's compiled in, and how will it affect those running python stuff who don't actually need it? If it turns out that only a few ports need it and the impact is undesirable those ports that do need it could be adapted to test for it somehow and suggest that the user re-install python with the option. HUGE_STACK_SIZE actually refers to the stack size used for each thread other than the primary thread. As I understand it, these stacks are fully committed while the thread exists, which is different to the handling of the primary thread's stack (where only the pages used are committed). On 32 bit systems, careless use of large thread stacks can cause non-trivial address space wastage. People don't see the same issues on Linux as it has a much larger default thread stack size and I'm lead to believe that only the pages in use in the thread stacks are committed. Since Python 2.5, there has been a way to change the thread stack size at runtime: threading.stack_size(). Ports patches using these calls for packages likely to be affected (such as Zope) could make this easier for a lot of people, if support for them can't be encouraged upstream. -- - Andrew I MacIntyre These thoughts are mine alone... E-mail: andy...@bullseye.apana.org.au (pref) | Snail: PO Box 370 andy...@pcug.org.au (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ 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
