Re: gcc bug? Openoffice port impossibel to compile on 4.8
On Thursday 22 May 2003 10:23 am, Julian Elischer wrote:
> I have rebuilt my system several times and rebuilt all ports..
> /usr/ports/editors/openoffice always ends up with:
GCC 3.2 is broken by design. It insists, amongst other stupidities, on
type-checking arguments using old style declarations like:
int foo(bar)
char *bar;
{}
rendering most UNIX software from before 1996 uncompilable. This is
biting one of my ports, I can't figure out how to shut the fscking thing
up, and am pretty much beyond caring. The Powers That Be in GCC-land
seem to have decided for us the world doesn't need any stinking
20-year-old software.
--
Where am I, and what am I doing in this handbasket?
Wes Peters [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] changing the ToS in IP Header
Ashish Kulkarni wrote: > > The attached patch adds a new sysctl oid for support of a > > "net.inet.ip.default_tos" (default: 0). > > > > I sent it as a context diff, in case the kernel has changed > > more than a little since the last time I updated. > > > > Note: I only compile-tested this. > > Thanks a lot for the help, and especially the quick response :-) > > The patch worked perfectly for me (had to do some very minor modifications > as I was testing on 4.5-RELEASE). Would it be possible for this to be > committed to 5-CURRENT, or is it frozen for 5.1? I can imagine this being > useful to people ... The best place to send it is to a committer who lives in the networking code. The easiest way to find one is to go to the web page and do a CVS annotate on the file to see who touched it last in that area (or just look at recent commit log messages). Your best bet for something like this is probably the people who have modified it's names, followed by "@freebsd.org"; fo this file, see: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in_pcb.c kan, cjc, jlemon, imp, hsu, and sam are all @freebsd.org email addresses who have touched this file so far this year. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc problem/openoffice failure
On 27 May, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > "Bruce R. Montague" <[EMAIL PROTECTED]> writes: > : > : Julian Elischer wrote: > : > : > ... I have not been able to compile the openoffice port ... > : > : > ... Has anyone else seen this? > : > : > : I tried to build openoffice on a "clean" -current system, > : built from a recent cvsup, and it failed to compile... This > : was perhaps a week and a half ago, kept meaning to get back > : and look at it, but time seems to have got the best of me. > > I wouldn't attempt something this complex without portupgrade... That reminds me ... the openoffice port ignores non-zero exit status in too many places. More than once I've had the install phase (and maybe even the build phase fail which then proceeded to the install phase which then failed), but the the exit status was ignored, make exited with a zero status, and portupgrade thought that the installation succeeded and then nuked the working backup copy of openoffice and did a make clean. A build from scratch takes more than 24 hours on my -stable box ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc problem/openoffice failure
On Tue, 27 May 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > "Bruce R. Montague" <[EMAIL PROTECTED]> writes: > : > : Julian Elischer wrote: > : > : > ... I have not been able to compile the openoffice port ... > : > : > ... Has anyone else seen this? > : > : > : I tried to build openoffice on a "clean" -current system, > : built from a recent cvsup, and it failed to compile... This > : was perhaps a week and a half ago, kept meaning to get back > : and look at it, but time seems to have got the best of me. > > I wouldn't attempt something this complex without portupgrade... > > Warner this WAS under port-upgrade.. run 3 times sequentially of course now that I've said this, it may have decided to go past the spot where it failed last time. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc problem/openoffice failure
In message: <[EMAIL PROTECTED]> "Bruce R. Montague" <[EMAIL PROTECTED]> writes: : : Julian Elischer wrote: : : > ... I have not been able to compile the openoffice port ... : : > ... Has anyone else seen this? : : : I tried to build openoffice on a "clean" -current system, : built from a recent cvsup, and it failed to compile... This : was perhaps a week and a half ago, kept meaning to get back : and look at it, but time seems to have got the best of me. I wouldn't attempt something this complex without portupgrade... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc problem/openoffice failure
On 27 May, Julian Elischer wrote: > > For the last month (more actually)(and after completely rebuilding my > system and all the ports on it) I have not been able to compile > the openoffice port due to gcc failures. > (I have posted the message earlier several times) > Has anyone been able to compile the openoffice port recently? > > somewhere in it's private compilation of mozilla (why does it do that? I > already have mozilla running?) gcc (doing c++) has a heart attach and > keels over dead. I think the reason to make the build take longer. Lots of fun on 400 MHz PII. > This has been reproducible for me for at least a month and probably > more. > > Has anyone else seen this? > Is the openoffice port working for everyone else? > (on FreeBSD 4.8++) (4.8-RELEASE had the same problem for me) I was able to build it on April 22. I don't know when the previous cvsup and buildworld was. My kernel.old dates to April 25th, so I don't have any history before that time. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc problem/openoffice failure
Julian Elischer wrote: > ... I have not been able to compile the openoffice port ... > ... Has anyone else seen this? I tried to build openoffice on a "clean" -current system, built from a recent cvsup, and it failed to compile... This was perhaps a week and a half ago, kept meaning to get back and look at it, but time seems to have got the best of me. - bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hey, man
On Tue, May 27, 2003 at 11:58:29PM +, Nikolai Krylenko wrote: > What's up? I hear you use Debian! WORST TROLL EVER! Kris pgp0.pgp Description: PGP signature
gcc problem/openoffice failure
For the last month (more actually)(and after completely rebuilding my system and all the ports on it) I have not been able to compile the openoffice port due to gcc failures. (I have posted the message earlier several times) Has anyone been able to compile the openoffice port recently? somewhere in it's private compilation of mozilla (why does it do that? I already have mozilla running?) gcc (doing c++) has a heart attach and keels over dead. This has been reproducible for me for at least a month and probably more. Has anyone else seen this? Is the openoffice port working for everyone else? (on FreeBSD 4.8++) (4.8-RELEASE had the same problem for me) julian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hey, man
What's up? I hear you use Debian! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Rrrrrr.....
Dear Bill, On 27-May-2003 Bill Paul wrote: > Ok, I've gotten enough e-mail about this now that it's starting to be > annoying, so I'm going to nip this in the bud right now. If this was prompted by my private email earlier today then I am sorry to have been the straw that broke your back. Having searched the archives over the past couple of days and not finding too much hard information on this chipset I decided a short note to you might speed up the effort I am making in porting the Linux driver. Maybe I didn't make that clear. I have been posting to -current and -mobile on the topic over the past week. The information below confirming that the API is different is all that I asked for. I will carry on with my porting effort. Thanks Duncan > People have started asking me about the Broadcom 4400 series chips. > They have noticed that there's this "if_bge" driver with the word > "Broadcom" associated with it, and seem to think it may somehow be > coerced into working with the 44xx chipset, even though the documentation > implies nothing of the sort. So everybody listen up: > > *NO*, the 44xx chips are *NOT* the same as the 57xx chips. The 57xx > devices are 10/100/1000. The 44xx are 10/100 *ONLY*. > > *NO* they do *NOT* have the same programming API. > > *NO*, the bge(4) driver will *NOT* work with the 44xx chips. Ever. I don't > care how much you whine. > > *NO* I don't have any programming manuals for the 44xx chips and don't > know (or care) if I ever will. > > *NO* I will *NOT* port the Linux driver to FreeBSD. > > Is everyone clear on this now? Good, because any further questions > along these lines will be summarily ignored. > > -Bill > > -- > = > -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu > [EMAIL PROTECTED] | Wind River Systems > = > "If stupidity were a handicap, you'd have the best parking spot." > = -- Duncan Barclay | [EMAIL PROTECTED] | [EMAIL PROTECTED]| ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
doing things around rc.d/diskless
On some diskless 4.x systems, I've got the following patch in place to let me do things before and after rc.diskless2 does it's stuff: Index: rc.diskless2 === RCS file: /usr/cvs/src/etc/Attic/rc.diskless2,v retrieving revision 1.5.2.14 diff -u -r1.5.2.14 rc.diskless2 --- rc.diskless223 Dec 2002 17:39:06 - 1.5.2.14 +++ rc.diskless224 May 2003 00:33:22 - @@ -51,6 +51,10 @@ . /etc/rc.conf fi +if [ -r /etc/rc.diskless2_pre ]; then + . /etc/rc.diskless2_pre +fi + # If we do not have a writable /var, create a memory # filesystem for /var. We don't have /usr yet so # use mkdir instead of touch to test. We want mount @@ -135,3 +139,6 @@ rm -f /tmp/dev.cpio.gz fi +if [ -r /etc/rc.diskless2_post ]; then + . /etc/rc.diskless2_post +fi In practice, I use rc.diskless2_pre to do some checks to make sure the system's disk is partitioned the way I want it, fix it if it's isn't, and mount /var so diskless2 won't make a new one that "mount -a" will immedialy hide. rc.diskless2_post is used to populate /var with non-standard things. What's the right way to do this in the rc.d world? It seems like I could add more scripts which will run before and after rc.d/diskless, but I don't understand rc.d all that well. Thanks, Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: changing the ToS in IP Header
Kenjiro Cho <[EMAIL PROTECTED]> wrote: > Tell your ISP not to use 0x02; it violates the standard. > You may modify the upper 6 bits for an arbitrary value, though. Well, my cable ISP provides a 3rd party Windows-only client that enables forwarding of packets only when logged in. I've reverse engineering that protocol sucessfully, and it requires the TOS to be 0x02 ... I imagine this TOS is only valid uptil the gateway, after which a different TOS is used. Anyway, all this is unofficial so I can't really go to my ISP and mention it ;-) > The lower 2 bits of the (now deprecated) TOS field are officially > assigned to ECN (RFC3168). 0x02, ECT(0), is used to indicate that the > sender is ECN-capable. > > ALTQ supports diffserv and is capable of rewriting the upper 6 bits of > the TOS field. > http://www.csl.sony.co.jp/~kjc/software.html I have one question: as you said, I can use ALTQ to reset all the upper 6 bits to zero, so as to get the pattern 0x02 (using the kernel patch by Terry Lambert). Will this have any implications for its working and for ECN? I need this because several protocols (ssh, etc) use a modified TOS, which I want to be reset to default value. Thanks, Ashish ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
rc.diskless1/initdiskless change for review
The following patch (against rc.diskless1 on STABLE, but the code is
identical in rc.d/initdiskless) simplifies the likely common case for
remounts in the /conf hierarchy. It allows you to specify a path (i.e.
/etc) in the diskless_remount file rather then having to record the path
to the NFS root. I'm using this to allow me to copy a the entire root
to a new location on my NFS server to do an upgrade without breaking
running hosts on the old root and without touching /conf at all.
I'd like to commit this after the tree is thawed again. What do people
think?
-- Brooks
Index: rc.diskless1
===
RCS file: /usr/cvs/src/etc/Attic/rc.diskless1,v
retrieving revision 1.5.2.11
diff -u -r1.5.2.11 rc.diskless1
--- rc.diskless114 Apr 2003 18:12:05 - 1.5.2.11
+++ rc.diskless124 May 2003 00:33:19 -
@@ -121,6 +121,17 @@
done
echo "Interface ${bootp_ifc} IP-Address ${bootp_ipa} Broadcast ${bootp_ipbca}"
+# Figure out our NFS root path
+#
+set `mount -t nfs`
+while [ $# -ge 1 ] ; do
+if [ "$2" = "on" -a "$3" = "/" ]; then
+nfsroot="$1"
+break
+fi
+shift
+done
+
# Resolve templates in /conf/base, /conf/default, /conf/${bootp_ipbca},
# and /conf/${bootp_ipa}. For each subdirectory found within these
# directories:
@@ -136,6 +147,10 @@
# might contain 'myserver:/etc'. NFS remounts allow you to avoid
# having to dup your system directories in /conf. Your server must
# be sure to export those filesystems -alldirs, however.
+# If the diskless_remount file contains a string beginning with a
+# '/' it is assumed that the local nfsroot should be prepended to
+# it before attemping to mount allowing the root to be relocated
+# without needing to change the remount files.
#
for i in base default ${bootp_ipbca} ${bootp_ipa} ; do
for j in /conf/$i/* ; do
@@ -150,6 +165,9 @@
#
if [ -d $j -a -f $j/diskless_remount ]; then
nfspt=`/bin/cat $j/diskless_remount`
+if [ `expr "$nfspt" : '\(.\)'` = "/" ]; then
+nfspt="${nfsroot}${nfspt}"
+fi
mount_nfs $nfspt $j
chkerr $? "mount_nfs $nfspt $j"
fi
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgp0.pgp
Description: PGP signature
Re: [PATCH] changing the ToS in IP Header
> > The attached patch adds a new sysctl oid for support of a > "net.inet.ip.default_tos" (default: 0). > > I sent it as a context diff, in case the kernel has changed > more than a little since the last time I updated. > > Note: I only compile-tested this. > Thanks a lot for the help, and especially the quick response :-) The patch worked perfectly for me (had to do some very minor modifications as I was testing on 4.5-RELEASE). Would it be possible for this to be committed to 5-CURRENT, or is it frozen for 5.1? I can imagine this being useful to people ... Thanks, Ashish ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Rrrrrr.....
Ok, I've gotten enough e-mail about this now that it's starting to be annoying, so I'm going to nip this in the bud right now. People have started asking me about the Broadcom 4400 series chips. They have noticed that there's this "if_bge" driver with the word "Broadcom" associated with it, and seem to think it may somehow be coerced into working with the 44xx chipset, even though the documentation implies nothing of the sort. So everybody listen up: *NO*, the 44xx chips are *NOT* the same as the 57xx chips. The 57xx devices are 10/100/1000. The 44xx are 10/100 *ONLY*. *NO* they do *NOT* have the same programming API. *NO*, the bge(4) driver will *NOT* work with the 44xx chips. Ever. I don't care how much you whine. *NO* I don't have any programming manuals for the 44xx chips and don't know (or care) if I ever will. *NO* I will *NOT* port the Linux driver to FreeBSD. Is everyone clear on this now? Good, because any further questions along these lines will be summarily ignored. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vlan/bridging broken in 4.8-release?
Hello Maxim, today I've tried your hack and it works, at least it seems so. It was not exactly the same setup but nearly the same. The bridge has two interfaces (fxp0, fxp1) and one host is connected to each interface (using crosslink cables, no other networking devices such as broken HP ProCurve switches). The host on fxp1 (10.10.10.16) does not use vlans, the host on fxp0 (10.10.10.18) is in vlan id 1. tcpdump -tni fxp0, fxp1, vlan0: (yes 10.10.10.18 has a strange mac address, because of a broken fxp0 card I guess ;) 6:0:ff:1:6:0 ff:ff:ff:ff:ff:ff 0806 56: arp who-has 10.10.10.16 tell 10.10.10.18 0:d0:b7:17:5:78 6:0:ff:1:6:0 0806 60: arp reply 10.10.10.16 is-at 0:d0:b7:17:5:78 6:0:ff:1:6:0 0:d0:b7:17:5:78 0800 98: 10.10.10.18 > 10.10.10.16: icmp: echo request 0:d0:b7:17:5:78 6:0:ff:1:6:0 0800 98: 10.10.10.16 > 10.10.10.18: icmp: echo reply 6:0:ff:1:6:0 ff:ff:ff:ff:ff:ff 8100 60: 802.1Q vlan#1 P0 arp who-has 10.10.10.16 tell 10.10.10.18 0:d0:b7:17:5:78 6:0:ff:1:6:0 8100 64: 802.1Q vlan#1 P0 arp reply 10.10.10.16 is-at 0:d0:b7:17:5:78 6:0:ff:1:6:0 0:d0:b7:17:5:78 8100 102: 802.1Q vlan#1 P0 10.10.10.18 > 10.10.10.16: icmp: echo request 0:d0:b7:17:5:78 6:0:ff:1:6:0 8100 102: 802.1Q vlan#1 P0 10.10.10.16 > 10.10.10.18: icmp: echo reply 6:0:ff:1:6:0 0:d0:b7:17:5:78 0800 98: 10.10.10.18 > 10.10.10.16: icmp: echo request 0:d0:b7:17:5:78 6:0:ff:1:6:0 0800 98: 10.10.10.16 > 10.10.10.18: icmp: echo reply 6:0:ff:1:6:0 0:d0:b7:17:5:78 8100 102: 802.1Q vlan#1 P0 10.10.10.18 > 10.10.10.16: icmp: echo request 0:d0:b7:17:5:78 6:0:ff:1:6:0 8100 102: 802.1Q vlan#1 P0 10.10.10.16 > 10.10.10.18: icmp: echo reply Two pings were send successfully with your hack and I guess everything else would work too, but I have no time for further testing, maybe the people who wrote the PR have more time ... Please make a real patch out of your hack and get it commited into -stable because I still want to use it for one of my customers :) Hopefully I did not forget anything in this email :) -- Mit freundlichen Gruessen, Marco Wertejuk - mwcis.com Consulting & Internet Solutions ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
