Re: addition to cdefs
Marc Recht [EMAIL PROTECTED] writes: I've had the attached patch in my tree for a while. I'll try and get it and the unistd.h patch committed today. Thanks! This solves some problems, but there are some left. Mostly socket and rpc related. For example PF_INET and friends are undefined.. This one looks like a problem on Python's end. sys/socket.h is new in POSIX.1-2001, so including it in a strictly conforming older POSIX or X/Open program is wrong. I could recommend either specifying 200112 for the POSIX version (likewise the X/Open) constant or not specifying a standard. The whole point of the standards constants is to specify a strict environment. If you want a BSD environment don't specify a particular standard, it's simple. I'm thinking more of it like an aggregation. IMHO it should be possible, if the user wants to, to get POSIX 199506 and BSD. With no standard environment specified, all POSIX.1-1996 objects should still be available. Can you provide an example where no constants specified would differ from _BSD_SOURCE and _POSIX_C_SOURCE being specified? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Mon Nov 11 02:03:55 GMT 2002 -- === ipfilter cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/vm/uma_dbg.c: In function `uma_dbg_alloc': /tinderbox/sparc64/src/sys/vm/uma_dbg.c:233: warning: implicit declaration of function `atomic_set_8' *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Fri Nov 8 08:01:22 GMT 2002 -- === ipfilter linking kernel.debug machdep.o(.bss+0x0): multiple definition of `physmem' vm_init.o(.bss+0x0): first defined here *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Fri Nov 8 14:03:12 GMT 2002 -- === ipfilter linking kernel.debug machdep.o(.bss+0x0): multiple definition of `physmem' vm_init.o(.bss+0x0): first defined here *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/etc rc.subr
On Fri, Nov 08, 2002 at 06:26:13PM -0800, Doug Barton wrote: I'm not sure I like this change actually... having the debug output go to syslog is very useful if you don't have a console on the system for whatever reason. I agree. It's also usefull when you're in an X session or other console messages have scrolled the output out of the buffer. Cheers, Mike. -- GPG Key: http://www.identd.net/~mtm/gpg.key pub 1024D/7D39509A 2002-10-08 Mike Makonnen [EMAIL PROTECTED] Key fingerprint = 5491 488A 0445 2DCC 777B 1F03 F3AB F9F8 7D39 509A msg46409/pgp0.pgp Description: PGP signature
Re: rc.d and sysctl.conf
On Wed, Oct 30, 2002 at 02:36:01PM -0800, Bill Fenner wrote: [ snip ] The update to the /etc/rc.d infrastructure keeps the ability to run twice, but does not actually run it twice. I started creating an /etc/rc.d/sysctl-last that would run /etc/rc.d/sysctl lastload, but realized that I didn't know how to say where the first/second call should go. To strictly follow /etc/rc.d, I could change the existing /etc/rc.d/sysctl to say BEFORE: serial and add BEFORE: securelevel to sysctl-last, but I'm not sure this is appropriate given the meta-checkpoints that we have. One of the hard things while I was doing the porting was deciding whether something in /etc/rc was there because it *must* run before the commands that were after it and after the commands that came before it. Since there haven't been any complaints in that regard I don't think the current order has broken anything. The general rule is to put something in REQUIRE and/or BEFORE only if it is necessary that some script be run before or after the current script. So, if the sysctls *must* be set before SERIAL, it should be in the BEFORE line. Otherwise, I would leave it as is and run `/etc/rc.d/sysctl lastload' in /etc/rc.d/securelevel just before rasing the securelevel (Please see the attached patch). (It also raises the question of if /etc/rc.d/securelevel actually runs at the right time. /etc/rc puts it almost at the absolute end, while rcorder sticks it somewhere in the middle -- number 67 of 102 on my system.) We wanted to keep the differences between our scripts and NetBSD's to a minimum. So, if it turns out we've broken something because of where rcorder puts the securelevel script, then we'll have to modify the BEFORE line of the affected script. Cheers, Mike -- GPG Key: http://www.identd.net/~mtm/gpg.key pub 1024D/7D39509A 2002-10-08 Mike Makonnen [EMAIL PROTECTED] Key fingerprint = 5491 488A 0445 2DCC 777B 1F03 F3AB F9F8 7D39 509A msg46410/pgp0.pgp Description: PGP signature
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- === usr.sbin/ntp/ntpd make: don't know how to make ntp_resolver.c. Stop *** Error code 2 Stop in /tinderbox/sparc64/src/usr.sbin/ntp. *** Error code 1 Stop in /tinderbox/sparc64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === sbin/disklabel In file included from /tinderbox/sparc64/src/sbin/disklabel/disklabel.c:73: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include/sys/sun_disklabel.h:103: syntax error before sizeof *** Error code 1 Stop in /tinderbox/sparc64/src/sbin/disklabel. *** Error code 1 Stop in /tinderbox/sparc64/src/sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Oct 26 07:58:58 GMT 2002 -- === ipfilter ./aicasm: 877 instructions used /tinderbox/sparc64/src/sys/kern/kern_sig.c:77:2: #error You *really* want COMPAT_FREEBSD4 on -current for a while mkdep: compile failed *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Oct 26 02:02:12 GMT 2002 -- === ipfilter ./aicasm: 877 instructions used /tinderbox/sparc64/src/sys/kern/kern_sig.c:77:2: #error You *really* want COMPAT_FREEBSD4 on -current for a while mkdep: compile failed *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === usr.sbin/sysinstall /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c: In function `dmenuOpen': /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:291: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:295: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:299: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/usr.sbin/sysinstall/menus.c:1370: warning: initialization makes integer from pointer without a cast disks.o: In function `diskPartitionWrite': disks.o(.text+0x14b8): undefined reference to `Write_Disk' wizard.o: In function `slice_wizard': wizard.o(.text+0x5e4): undefined reference to `Write_Disk' *** Error code 1 Stop in /tinderbox/sparc64/src/usr.sbin/sysinstall. *** Error code 1 Stop in /tinderbox/sparc64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === usr.sbin/sysinstall /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c: In function `dmenuOpen': /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:291: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:295: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:299: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/usr.sbin/sysinstall/menus.c:1370: warning: initialization makes integer from pointer without a cast disks.o: In function `diskPartitionWrite': disks.o(.text+0x14b8): undefined reference to `Write_Disk' wizard.o: In function `slice_wizard': wizard.o(.text+0x5e4): undefined reference to `Write_Disk' *** Error code 1 Stop in /tinderbox/sparc64/src/usr.sbin/sysinstall. *** Error code 1 Stop in /tinderbox/sparc64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- === lib/libdisk cc1: warnings being treated as errors /tinderbox/sparc64/src/lib/libdisk/disk.c:428: warning: `assignToPartition' defined but not used *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libdisk. *** Error code 1 Stop in /tinderbox/sparc64/src/lib. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === usr.sbin/pkg_install/info cc1: warnings being treated as errors /tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c: In function `show_size': /tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c:239: warning: passing arg 1 of `getbsize' from incompatible pointer type *** Error code 1 Stop in /tinderbox/sparc64/src/usr.sbin/pkg_install/info. *** Error code 1 Stop in /tinderbox/sparc64/src/usr.sbin/pkg_install. *** Error code 1 Stop in /tinderbox/sparc64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Installworld fails building Current from 4.7-R
On Thu, 24 Oct 2002, Richard Cotrina wrote: Yes, I did. However make installworld fails as I said. I ran into the same problem going from 4.6 to 5.0-CURRENT. We used truss to see that sh was making funny calls, and concluded that we'd need to run from the kernel to get it working. We installed the new kernel and were able to complete the install. Definitely not knowledgeable enough to be posting to freebsd-current, Mike Hunter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === sbin/ipfw /tinderbox/sparc64/src/sbin/ipfw/ipfw2.c: In function `show_ipfw': /tinderbox/sparc64/src/sbin/ipfw/ipfw2.c:814: structure has no member named `set_disable' /tinderbox/sparc64/src/sbin/ipfw/ipfw2.c: In function `show_dyn_ipfw': /tinderbox/sparc64/src/sbin/ipfw/ipfw2.c:1201: structure has no member named `rulenum' /tinderbox/sparc64/src/sbin/ipfw/ipfw2.c: In function `sets_handler': /tinderbox/sparc64/src/sbin/ipfw/ipfw2.c:1435: structure has no member named `set_disable' /tinderbox/sparc64/src/sbin/ipfw/ipfw2.c: In function `list': /tinderbox/sparc64/src/sbin/ipfw/ipfw2.c:1621: structure has no member named `rulenum' /tinderbox/sparc64/src/sbin/ipfw/ipfw2.c:1623: structure has no member named `rulenum' *** Error code 1 Stop in /tinderbox/sparc64/src/sbin/ipfw. *** Error code 1 Stop in /tinderbox/sparc64/src/sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libstdc++ does not contain fabsl symbol
David Schultz [EMAIL PROTECTED] writes: Thus spake Mike Barcroft [EMAIL PROTECTED]: No one has started work on any of the C99 math functions yet. I think with the exception of the math functions we conform to C99. Actually, I hacked up some patches for fpclassify(), is*(), and friends some time ago. But nobody was interested in compliance at the time except for a couple of port maintainers, so I didn't bother finishing it up. In any case, I no longer have the time. (It's fairly easy, given that some of the code is already there, but a bit more work to optimize for every architecture FreeBSD supports.) Note that while you're adding the C99 math stuff, you might want to fix up float.h, which is just wrong about long doubles (see PR i386/38288). Right, I should have said no one has started committing C99 math functions. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === bin/df cc1: warnings being treated as errors /tinderbox/sparc64/src/bin/df/df.c: In function `prtstat': /tinderbox/sparc64/src/bin/df/df.c:394: warning: passing arg 1 of `getbsize' from incompatible pointer type /tinderbox/sparc64/src/bin/df/df.c: In function `update_maxwidths': /tinderbox/sparc64/src/bin/df/df.c:447: warning: passing arg 1 of `getbsize' from incompatible pointer type *** Error code 1 Stop in /tinderbox/sparc64/src/bin/df. *** Error code 1 Stop in /tinderbox/sparc64/src/bin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
Wed Oct 23 09:03:00 GMT 2002 cvs [update aborted]: /home/ncvs/CVSROOT: Interrupted system call To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- === lib/libdisk cc1: warnings being treated as errors /tinderbox/sparc64/src/lib/libdisk/disk.c:428: warning: `assignToPartition' defined but not used *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libdisk. *** Error code 1 Stop in /tinderbox/sparc64/src/lib. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libstdc++ does not contain fabsl symbol
Kris Kennaway [EMAIL PROTECTED] writes: On Tue, Oct 22, 2002 at 11:22:41AM +0300, Ruslan Ermilov wrote: On Sat, Oct 19, 2002 at 07:54:01PM -0700, Kris Kennaway wrote: World is broken if you try and build with -fno-builtin: c++ -O -pipe -ggdb -fno-builtin -march=pentium3 -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -o gperf bool-array.o gen-perf.o hash-table.o iterator.o key-list.o list-node.o main.o new.o options.o read-line.o trace.o vectors.o version.o hash.o getopt.o getopt1.o gen-perf.o: In function `Gen_Perf::Gen_Perf()': /usr/src/contrib/gperf/src/bool-array.icc:81: warning: rand() does not produce high-quality random numbers and should not generally be used /usr/obj/usr/src/i386/usr/lib/libstdc++.so: undefined reference to `fabsl' *** Error code 1 This is because we lack the long double fabsl(long double); in -lm and math.h. OK, thanks for tracking it down. This looks like an important omission that should be fixed for 5.0-R. No one has started work on any of the C99 math functions yet. I think with the exception of the math functions we conform to C99. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Oct 22 01:49:54 GMT 2002 -- === msdosfs /tinderbox/sparc64/src/sys/fs/msdosfs/msdosfs_vfsops.c: In function `mountmsdosfs': /tinderbox/sparc64/src/sys/fs/msdosfs/msdosfs_vfsops.c:342: structure has no member named `bsPBP' *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/msdosfs. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Oct 13 12:22:09 GMT 2002 -- === ipfilter In file included from @/sys/signal.h:47, from @/sys/proc.h:52, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_compat.h:596, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/mlfk_ipl.c:50: machine/signal.h:49:12: #if with no expression In file included from @/sys/signal.h:47, from @/sys/proc.h:52, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_compat.h:596, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_nat.c:95: machine/signal.h:49:12: #if with no expression In file included from @/sys/signal.h:47, from @/sys/proc.h:52, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_compat.h:596, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_frag.c:65: machine/signal.h:49:12: #if with no expression In file included from @/sys/signal.h:47, from @/sys/proc.h:52, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_compat.h:596, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_state.c:78: machine/signal.h:49:12: #if with no expression In file included from @/sys/signal.h:47, from @/sys/proc.h:52, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_compat.h:596, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_proxy.c:68: machine/signal.h:49:12: #if with no expression In file included from @/sys/signal.h:47, from @/sys/proc.h:52, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_compat.h:596, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_auth.c:88: machine/signal.h:49:12: #if with no expression In file included from @/sys/signal.h:47, from @/sys/proc.h:52, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_compat.h:596, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_log.c:112: machine/signal.h:49:12: #if with no expression In file included from @/sys/signal.h:47, from @/sys/proc.h:52, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_compat.h:596, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_fil.c:97: machine/signal.h:49:12: #if with no expression In file included from @/sys/signal.h:47, from @/sys/proc.h:52, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/ip_compat.h:596, from /tinderbox/sparc64/src/sys/contrib/ipfilter/netinet/fil.c:73: machine/signal.h:49:12: #if with no expression mkdep: compile failed *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/ipfilter. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: imake-4 build broken
Vallo Kallaste [EMAIL PROTECTED] writes: On Thu, Oct 10, 2002 at 08:03:00PM -0400, Mike Barcroft [EMAIL PROTECTED] wrote: imake-4 port building is broken. I guess that's because xc/config/makedepend/main.c defines _POSIX_SOURCE before including signal.h. Signal.h includes sys/signal.h which has conditional #if !defined(_POSIX_SOURCE) and NSIG will be left undefined. Don't know who is in fault here, imake sources or our headers, my knowledge happens to end there. I don't really understand how this is happening. The uses of NSIG are also conditionalized. If _POSIX_SOURCE is defined, line 46 should not be visible. What rev is your /usr/include/sys/cdefs.h and /usr/include/signal.h? /usr/include/sys/cdefs.h: $FreeBSD: src/sys/sys/cdefs.h,v 1.67 2002/10/07 02:50:44 mike Exp $ $FreeBSD: src/sys/sys/cdefs.h,v 1.67 2002/10/07 02:50:44 mike Exp $ /usr/include/signal.h: $FreeBSD: src/include/signal.h,v 1.19 2002/10/06 21:54:08 mike Exp $ The same error happens several times down the road of XFree86-4 port compilation and all the problematic source files contain #include signal.h surrounded by _POSIX_SOURCE. Removing this _POSIX_SOURCE thing got the XFree86-4 port compile to me. I've just committed the rest of my signal.h-related patches, can you update your system and let me know if I've fixed the problem. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- === gnu/usr.bin/binutils/libbfd In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h: In function `elf_slurp_reloc_table_from_section': /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1398: warning: implicit declaration of function `bfd_get_dynamic_symcount' In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `elf_add_default_symbol': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1069: warning: passing arg 1 of pointer to function from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1069: too few arguments to function /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1136: warning: passing arg 1 of pointer to function from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1136: too few arguments to function In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: At top level: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:2497: conflicting types for `elf_link_record_local_dynamic_symbol' /tinderbox/sparc64/src/contrib/binutils/bfd/elf-bfd.h:1564: previous declaration of `elf_link_record_local_dynamic_symbol' In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `elf_fix_symbol_flags': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:3952: warning: passing arg 1 of pointer to function from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:3952: too few arguments to function In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `elf_link_input_bfd': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:6911: warning: assignment from incompatible pointer type In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `_bfd_elf32_gc_sections': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:7865: warning: assignment from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `_bfd_elf32_reloc_symbol_deleted_p': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8182: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `bfd_elf32_discard_info': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8312: warning: assignment from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8322: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8327: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8328: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8331: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8333: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8388: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8389: structure has no member named `locsym_shndx' *** Error code 1 Stop in /tinderbox/sparc64/src/gnu/usr.bin/binutils/libbfd. *** Error code 1 Stop in /tinderbox/sparc64/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- === gnu/usr.bin/binutils/libbfd In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h: In function `elf_slurp_reloc_table_from_section': /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1398: warning: implicit declaration of function `bfd_get_dynamic_symcount' In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `elf_add_default_symbol': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1069: warning: passing arg 1 of pointer to function from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1069: too few arguments to function /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1136: warning: passing arg 1 of pointer to function from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1136: too few arguments to function In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: At top level: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:2497: conflicting types for `elf_link_record_local_dynamic_symbol' /tinderbox/sparc64/src/contrib/binutils/bfd/elf-bfd.h:1564: previous declaration of `elf_link_record_local_dynamic_symbol' In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `elf_fix_symbol_flags': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:3952: warning: passing arg 1 of pointer to function from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:3952: too few arguments to function In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `elf_link_input_bfd': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:6911: warning: assignment from incompatible pointer type In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `_bfd_elf32_gc_sections': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:7865: warning: assignment from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `_bfd_elf32_reloc_symbol_deleted_p': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8182: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `bfd_elf32_discard_info': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8312: warning: assignment from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8322: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8327: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8328: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8331: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8333: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8388: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8389: structure has no member named `locsym_shndx' *** Error code 1 Stop in /tinderbox/sparc64/src/gnu/usr.bin/binutils/libbfd. *** Error code 1 Stop in /tinderbox/sparc64/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP: GCC 3.2.1 update is coming
David O'Brien [EMAIL PROTECTED] writes: On Thu, Oct 10, 2002 at 08:38:58PM -0400, Alexander Kabaev wrote: Could you please try to compile libmsun with with GCC 3.3 snapshot David just committed and see if that changes anything? It doesn't compile on -current. Mike and the standards guys are suspose to undo the breakage that crept into out headers. For the daring, try to build the port and then change the two u_long that is complained about to unsigned long. I've committed this for now. The `#ifndef _POSIX_SOURCE' conditional needs to check for other standards, but I'll leave this until I have a chance to go through the entire header to make it conformant. This is a new problem because of rev 1.74 of sys/types.h where a conditional was updated to check for other standards, but had some dependencies that I wasn't aware of and world didn't find them for me. If there are any others I should find them as I go through each standard header. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: imake-4 build broken
Vallo Kallaste [EMAIL PROTECTED] writes: Hi imake-4 port building is broken. I guess that's because xc/config/makedepend/main.c defines _POSIX_SOURCE before including signal.h. Signal.h includes sys/signal.h which has conditional #if !defined(_POSIX_SOURCE) and NSIG will be left undefined. Don't know who is in fault here, imake sources or our headers, my knowledge happens to end there. I don't really understand how this is happening. The uses of NSIG are also conditionalized. If _POSIX_SOURCE is defined, line 46 should not be visible. What rev is your /usr/include/sys/cdefs.h and /usr/include/signal.h? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE 3.0 broken in current??
Terry Lambert [EMAIL PROTECTED] writes: KDE is broken; it's assuming promisucous headers. This could be our fault. We advertise ourselves as POSIX.1-2001 conformant, but only about 2/3 of our standard headers are. I'm systematically working my through them, but some issues take longer to solve than others. Workaround: mv netdev.c netdev.c.broken echo #include sys/types.h netdev.c cat netdev.c.broken netdev.c Probably, this should be handled by sending a patch back to the KDE folks, whose servers were dead and being repaired yesterday. You could also make a port path that patched netdev.c, as an interim fix (include the header before including the sys/socket.h header). Unfortunately, It still has not been 72 hours for the download, so I still do not have the KDE sources available locally. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: hotspot 1.3.1 not such ansi.h file error
suken woo [EMAIL PROTECTED] writes: hi,all: get the error messages during gmake core gmake[1]: Entering directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake[2]: Entering directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' Compiling /usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/../../src/os/linux/vm/os_linux.cpp /usr/ports/java/jdk13/work/hotspot1.3.1/src/os/linux/vm/os_linux.cpp:49:26: machine/ansi.h: No such file or directory gmake[2]: *** [os_linux.o] Error 1 gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake[1]: *** [the_vm] Error 2 gmake[1]: Leaving directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake: *** [jvmgcore] Error 2 AFAICT the machine/ansi.h include here is bogus. Removing it should fix this. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
Nate Lawson [EMAIL PROTECTED] writes: Matt, something in your mcd commits (staticizing probe/attach) may have broken LINT. mcd.c intentionally creates an empty object file in the GEOM-defined (ie. LINT) case. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: expat2 in the base system?
Ernst de Haan [EMAIL PROTECTED] writes: If most file formats would be XML-based (yes I know XML should not replace all file formats, but it comes a great way) then these formats would be leveraged by the fact that there are a lot of XML tools available, like XML editors and XML transformation processors (XSLT). It's easy to convert from one XML format to the other, making the generation of DocBook or XHTML documents a /lot/ easier. I've always wondered what a Makefile would look like in XML. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fatal warnings breaks ipfw on LP64
It's been one month, have you made any progress on this? Mike Barcroft [EMAIL PROTECTED] writes: cc1: warnings being treated as errors /usr/src/sys/netinet/ip_fw2.c: In function `ipfw_ctl': /usr/src/sys/netinet/ip_fw2.c:2508: warning: cast from pointer to integer of different size /usr/src/sys/netinet/ip_fw2.c:2521: warning: cast from pointer to integer of different size Some of the code in question looks questionable: /* * abuse 'next_rule' to store the set_disable word */ (u_int32_t)(((struct ip_fw *)bp)-next_rule) = set_disable; The rvalue is being cast in an assignment to make a pointer store an integer? Surely this can be written better. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Tue, 24 Sep 2002, Alexander Kabaev wrote: On Tue, 24 Sep 2002 10:52:10 -0500 (CDT) Mike Silbersack [EMAIL PROTECTED] wrote: Do you want me to try your first patch? I never got a chance to test it.(And no longer have a copy of it, either.) No, there is a bug in the patch you tested. Could you please try again with an updated patch? URL is the same http://people.freebsd.org/~kan/gcc-cpp.diff -- Alexander Kabaev That doesn't seem to have fixed the problem, and the backtrace looks to be the same: #0 0x08058cb6 in cpp_ideq () #1 0x080592e6 in _cpp_lex_direct () #2 0x08058f6d in _cpp_lex_token () #3 0x08056465 in cpp_macro_definition () #4 0x080564ed in cpp_macro_definition () #5 0x0805672b in _cpp_handle_directive () #6 0x08058f9c in _cpp_lex_token () #7 0x08055832 in cpp_get_token () #8 0x0805595d in cpp_scan_nooutput () #9 0x08048409 in do_preprocessing () #10 0x08048241 in main () #11 0x08048145 in _start () Thanks to the wonderful sort breakage, I'm seeing this if I touch cppmacro.c and make again: === cc_int cc -O -pipe -mcpu=pentiumpro -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\i386-undermydesk-freebsd\ -DIN_GCC -c /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/cppmacro.c -o cppmacro.o building static cc_int library sort: open failed: +1: No such file or directory sort: open failed: +1: No such file or directory ranlib libcc_int.a Any chance that's causing a problem? Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Sun, 22 Sep 2002, Alexander Kabaev wrote: On Sun, 22 Sep 2002 18:51:14 -0500 (CDT) Mike Silbersack [EMAIL PROTECTED] wrote: I'm seeing the segfault in the kernel make depend step, just as someone else reported. OK, could you please try the patch at http://people.freebsd.org/~kan/gcc-cpp.diff and let me know the results. -- Alexander Kabaev This version of the gcc-cpp.diff patch: Index: cppmacro.c === RCS file: /usr/ncvs/src/contrib/gcc/cppmacro.c,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 cppmacro.c --- cppmacro.c 1 Sep 2002 20:37:29 - 1.1.1.4 +++ cppmacro.c 23 Sep 2002 17:44:32 - @@ -349,6 +349,8 @@ /* Commit the memory, including NUL, and return the token. */ len = dest - BUFF_FRONT (pfile-u_buff); + if ((size_t) (BUFF_LIMIT (pfile-u_buff) - dest) 1) +_cpp_extend_buff (pfile, pfile-u_buff, 1); BUFF_FRONT (pfile-u_buff) = dest + 1; return new_string_token (pfile, dest - len, len); } Does _not_ fix the problem for me. Here's the backtrace of the crash with the patch applied: #0 0x08058cb6 in cpp_ideq () #1 0x080592e6 in _cpp_lex_direct () #2 0x08058f6d in _cpp_lex_token () #3 0x08056465 in cpp_macro_definition () #4 0x080564ed in cpp_macro_definition () #5 0x0805672b in _cpp_handle_directive () #6 0x08058f9c in _cpp_lex_token () #7 0x08055832 in cpp_get_token () #8 0x0805595d in cpp_scan_nooutput () #9 0x08048409 in do_preprocessing () #10 0x08048241 in main () #11 0x08048145 in _start () And of course, it's this part of a buildkernel where it happens: make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. Do you want me to try your first patch? I never got a chance to test it. (And no longer have a copy of it, either.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Tue, 24 Sep 2002, David Wolfskill wrote: building static cc_int library sort: open failed: +1: No such file or directory sort: open failed: +1: No such file or directory ranlib libcc_int.a Any chance that's causing a problem? To fix that (regardless of sort), s/sort +1/sort -k 2/ in `which lorder` (and /usr/src/usr.bin/lorder/lorder.sh). Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill[EMAIL PROTECTED] Ok, I fixed lorder.sh, and made gcc again from clean with Alexander's patch. No change, I still see the same segmentation fault. Alexander, how can I easily build gcc with full debugging symbols? That might make the backtrace more useful for you. Or better yet, I'm just including my kernel config. Presumably with it you'll be able to recreate the problem on your system. If not, then we can see what else differs about my system. Mike Silby Silbersack # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the NOTES configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.308 2001/05/13 20:52:39 phk Exp $ machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident PATROCLES maxusers0 #options RANDOM_IP_ID options UFS_DIRHASH options DIAGNOSTIC #makeoptions NO_WERROR=true device smbus # Bus support, required for smb below. device intpm device alpm device ichsmb device smb device iicbus # Bus support, required for ic/iic/iicsmb below. device iicbb device ic device iic device iicsmb # smb over i2c bridge #device pcf #To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints #Default places to look for devices. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options DDB #optionsMATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options MD_ROOT #MD is a potential root device #optionsNFS #Network Filesystem #optionsNFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options PSEUDOFS options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev # Debugging for use in -current #optionsDDB #optionsINVARIANTS #optionsINVARIANT_SUPPORT #optionsWITNESS # To make an SMP kernel, the next two are needed #optionsSMP # Symmetric MultiProcessor Kernel #optionsAPIC_IO # Symmetric (APIC) I/O device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices
Re: -mcpu=pentiumpro still evil?
On Tue, 24 Sep 2002, Craig Rodrigues wrote: On Tue, Sep 24, 2002 at 02:05:08PM -0500, Mike Silbersack wrote: Ok, I fixed lorder.sh, and made gcc again from clean with Alexander's patch. No change, I still see the same segmentation fault. Alexander, how can I easily build gcc with full debugging symbols? That might make the backtrace more useful for you. Does this work for you: cd /usr/src/gnu/usr.bin/cc make DEBUG_FLAGS=-g install -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] Nope, that doesn't build in debugging symbols either. Neither does adding +g or +gstabs+ to CFLAGS in make.conf. Hmph. Maybe I need to add LDFLAGS or something, I'm not sure. (I'm really bad with Makefiles.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Tue, 24 Sep 2002, Alexander Kabaev wrote: On Tue, 24 Sep 2002 16:07:39 -0500 (CDT) Mike Silbersack [EMAIL PROTECTED] wrote: On Tue, 24 Sep 2002, Craig Rodrigues wrote: On Tue, Sep 24, 2002 at 02:05:08PM -0500, Mike Silbersack wrote: Ok, I fixed lorder.sh, and made gcc again from clean with Alexander's patch. No change, I still see the same segmentation fault. Alexander, how can I easily build gcc with full debugging symbols? That might make the backtrace more useful for you. cd /usr/src/gnu/usr.bin/cc CFLAGS=-g STRIP= make clean all install Always worked for me. -- Alexander Kabaev Yep, STRIP= was the necessary trick, I didn't realize that install -s meant strip. :) As to your patch... it turns out that I wasn't using it. I've been testing with make buildkernel, which uses the copy of gcc built by your last buildworld, not a more recent manual build of gcc. Hence, I've been testing the wrong version. I'll go ahead and run a full buildworld before testing again. Sorry about my poor testing practices. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Tue, 24 Sep 2002, Mike Silbersack wrote: Yep, STRIP= was the necessary trick, I didn't realize that install -s meant strip. :) As to your patch... it turns out that I wasn't using it. I've been testing with make buildkernel, which uses the copy of gcc built by your last buildworld, not a more recent manual build of gcc. Hence, I've been testing the wrong version. I'll go ahead and run a full buildworld before testing again. Sorry about my poor testing practices. Mike Silby Silbersack Ok, now that I tested properly, I can confirm that your generation 3 patch seems to solve the problem here. Please commit it asap! Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Question for committers.
walt [EMAIL PROTECTED] writes: May I ask a naïve question, please? World has been broken at libncurses for three days. There have been dozens of commits to the -CURRENT tree during that same three days. How do you committers to -CURRENT keep working when userland is broken? How can you judge the impact of all your changes when you are not rebuilding the system every day? I'm sure most of us aren't installing world each day, only building and installing certain things, or only building everything with an older world. You can also back out the unistd.h changes and rebuild sort locally. Please don't interpret this question as criticism--none is intended. I'm puzzled and I'd like to understand this process better, maybe even contribute to it someday when I know more. Thanks. BTW, what does MFC mean? Merge from -current usually into the -stable branch. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/include/sys/select.h:61: syntax error before fd_set
Marc Recht [EMAIL PROTECTED] writes: I'm trying to work out why the latest version of coldsync won't compile on -current, even though it compiles on -stable. I'm getting the compile time error: /usr/include/sys/select.h:61: syntax error before fd_set The coldsync header file looks like: What header am I missing here? sys/types.h (before sys/select.h) sys/select.h includes sys/types.h; see line 57 of rev 1.13. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Sun, 22 Sep 2002, Alexander Kabaev wrote: On Sat, 21 Sep 2002 23:10:51 -0500 (CDT) Mike Silbersack [EMAIL PROTECTED] wrote: Is anyone else still seeing Sig 11's from GCC when mcpu=pentiumpro is enabled (as it appears to be by default now)? I get a segfault in the same place every time when compiling a DIAGNOSTIC kernel when I leave it enabled. Just curious if this is just me or not... Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Please post an error message and a traceback from GCC if possible. I might have the patch for that. -- Alexander Kabaev Ok, I think this is the correct backtrace: #0 0x0806ccee in cpp_ideq () #1 0x0806d31e in _cpp_lex_direct () #2 0x0806cfa5 in _cpp_lex_token () #3 0x080589e1 in cpp_macro_definition () #4 0x08058a69 in cpp_macro_definition () #5 0x08058ca7 in _cpp_handle_directive () #6 0x0806cfd4 in _cpp_lex_token () #7 0x08057dae in cpp_get_token () #8 0x08057ed9 in cpp_scan_nooutput () #9 0x080483e1 in do_preprocessing () #10 0x08048219 in main () #11 0x08048131 in _start () I'm seeing the segfault in the kernel make depend step, just as someone else reported. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fixing ports/palm/coldsync.
Josef Karthauser [EMAIL PROTECTED] writes: On Sun, Sep 22, 2002 at 04:42:32PM +0100, Josef Karthauser wrote: Has anyone here got the time to help me out? I want to fix the uvisor code so that it works properly, but am getting caught up trying to fix the coldsync port. It compiles on -stable, but has been broken on -current for a while. Something changed in the fd_set area and it's not compiled for a long time. I'd really appreciate it is someone with a knowledge of select foo could help me work out what's wrong. Did we tighten something up in -current, or have we deprecated something? Mark Trettin [EMAIL PROTECTED] sent me a patch (attached for reference). This turns out to be a bug in our headers. I'm testing a patch which fixes sys/select.h in the standards case. I'll post it to -standards a little later if you want to test it. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 machine/endian.h
Wesley Morgan [EMAIL PROTECTED] writes: I've been playing around with lang/icc a bit, and find it quite vexing that machine/endian.h has macros that are ifdef'd around __GNUC__. The intel compiler does not like the macros, partly because they are split across multiple lines and possibly for other reasons. It seems to me that making a header actually _require_ gcc-isms is something that the FreeBSD team should be working away from... Would it not be possible to put make some more generic macros available as well? I'm sure it's not the only instance of similar issues, but making one header less gcc-dependent is a step in the right direction is it not? This was my fault. I wasn't paying attention closely to issues with other compilers. I've had the attached patch in my local tree for some time, but haven't had a chance to test it with ICC. Can you confirm it fixes the issues you're seeing? Best regards, Mike Barcroft Be careful not to define GCC-specific optimizations in the non-GCC case. Index: endian.h === RCS file: /work/repo/src/sys/i386/include/endian.h,v retrieving revision 1.34 diff -u -r1.34 endian.h --- endian.h21 Aug 2002 16:19:58 - 1.34 +++ endian.h22 Aug 2002 00:29:19 - @@ -117,11 +117,18 @@ return (__byte_swap_word(_x)); } -#endif /* __GNUC__ */ - #define__htonl(x) __bswap32(x) #define__htons(x) __bswap16(x) #define__ntohl(x) __bswap32(x) #define__ntohs(x) __bswap16(x) + +#else /* !__GNUC__ */ + +#undef htonl +#undef htons +#undef ntohl +#undef ntohl + +#endif /* __GNUC__ */ #endif /* !_MACHINE_ENDIAN_H_ */
Re: i386 machine/endian.h
Mike Barcroft [EMAIL PROTECTED] writes: Wesley Morgan [EMAIL PROTECTED] writes: I've been playing around with lang/icc a bit, and find it quite vexing that machine/endian.h has macros that are ifdef'd around __GNUC__. The intel compiler does not like the macros, partly because they are split across multiple lines and possibly for other reasons. It seems to me that making a header actually _require_ gcc-isms is something that the FreeBSD team should be working away from... Would it not be possible to put make some more generic macros available as well? I'm sure it's not the only instance of similar issues, but making one header less gcc-dependent is a step in the right direction is it not? This was my fault. I wasn't paying attention closely to issues with other compilers. I've had the attached patch in my local tree for some time, but haven't had a chance to test it with ICC. Can you confirm it fixes the issues you're seeing? I thought about this a little bit more, and the previous patch won't do anything unless two headers call machine/endian.h. A new patch which is much more likely to work is attached. Can you try this one instead? Best regards, Mike Barcroft Be careful not to define GCC-specific optimizations in the non-GCC case. Index: endian.h === RCS file: /work/repo/src/sys/i386/include/endian.h,v retrieving revision 1.34 diff -u -r1.34 endian.h --- endian.h21 Aug 2002 16:19:58 - 1.34 +++ endian.h23 Sep 2002 01:58:16 - @@ -117,11 +117,20 @@ return (__byte_swap_word(_x)); } -#endif /* __GNUC__ */ - #define__htonl(x) __bswap32(x) #define__htons(x) __bswap16(x) #define__ntohl(x) __bswap32(x) #define__ntohs(x) __bswap16(x) + +#else /* !__GNUC__ */ + +/* + * No optimizations are available for this compiler. Fall back to + * non-optimized functions by defining the constant usually used to prevent + * redefinition. + */ +#define_BYTEORDER_FUNC_DEFINED + +#endif /* __GNUC__ */ #endif /* !_MACHINE_ENDIAN_H_ */
Re: Who broke sort(1) ?
Tim Robbins [EMAIL PROTECTED] writes: On Sun, Sep 22, 2002 at 01:43:38PM -0700, Steve Kargl wrote: On Sun, Sep 22, 2002 at 10:17:41PM +0200, Poul-Henning Kamp wrote: flat# date | sort +5n sort: open failed: +5n: No such file or directory This breaks the build in libncurses... POSIX via wollman. See revision 1.58 of /usr/include/unistd.h, i.e., /* Define the versions we target for compliance. */ #define _POSIX_VERSION 200112L #define _POSIX2_VERSION 200112L See email in the last 24 hours from walt about problems building libc and Tim Robbins response to the problem. I didn't read src/contrib/gnu-sort/lib/posixver.c carefully enough to notice that it uses the the _POSIX2_VERSION macro, I thought it only used the environment variable by that same name. A workaround might be to #undef _POSIX2_VERSION after #include'ing unistd.h in posixver.c but I don't think that would be correct. It's probably better to either change all the scripts that use the obsolescent +pos -pos syntax to use the new -k syntax or to change _POSIX2_VERSION back to whatever it was before. I think the second is more realistic. I think we'd really like to target POSIX 2001 for 5.0-RELEASE, so the first solution would be best. Temporarily backing out the updated POSIX version bump might not be a bad idea if this is a task which will take a while. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 machine/endian.h
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: On Sun, Sep 22, 2002 at 09:57:57PM -0400, Mike Barcroft wrote: Mike Barcroft [EMAIL PROTECTED] writes: This was my fault. I wasn't paying attention closely to issues with other compilers. I've had the attached patch in my local tree for some time, but haven't had a chance to test it with ICC. Can you confirm it fixes the issues you're seeing? I thought about this a little bit more, and the previous patch won't do anything unless two headers call machine/endian.h. A new patch which is much more likely to work is attached. Can you try this one instead? Works fine, please commit. Done. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-mcpu=pentiumpro still evil?
Is anyone else still seeing Sig 11's from GCC when mcpu=pentiumpro is enabled (as it appears to be by default now)? I get a segfault in the same place every time when compiling a DIAGNOSTIC kernel when I leave it enabled. Just curious if this is just me or not... Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stage 2 build of contrib/file breaks upgrade from 4.7PRE to CURRENT.
Stefan Farfeleder [EMAIL PROTECTED] writes: [CC'ing David O'Brien as he did the update to 3.39] On Tue, Sep 17, 2002 at 09:38:10AM -0700, Lars Eggert wrote: Robert Suetterlin wrote: I currently upgraded my 4.4 to 4.7-PRE and now tried to get from there to -CURRENT. Unfortunately ``make buildworld'' fails during stage 2 when building ``usr.bin/file'': usr/src/usr.bin/file/../../contrib/file/file.h:45: stdint.h: No such file or directory FYI I'm seeing the exact same error trying to build -CURRENT under 4.6-RELEASE (just cvs updated). Add me to the list. Culprit is src/usr.bin/file/config.h which unconditionally defines HAVE_STDINT_H though RELENG_4 is missing it. This is being looked into. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Alpha fatal warning in kernel compile
Kris Kennaway [EMAIL PROTECTED] writes: On Thu, Sep 12, 2002 at 01:52:40PM -0700, Nate Lawson wrote: (who wants NO_WERROR back or better, warns-clean code more often in -current) NO_WERROR is standard in userland; it should work in the kernel too. Peter removed support for this a while ago. The easiest way to get around problems now is to edit sys/conf/files* and add a nowerror for each affected file. I think the idea is to force developers to test changes, so that they hit the errors before the tinderboxes and the rest of the developer base. In practice this doesn't stop the determined troublemakers. :) Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: uudecode troubles in sharte/tabset.
walt [EMAIL PROTECTED] writes: uudecode compiles again, but now I'm getting this making world: === share/tabset uudecode /usr/src/share/tabset/3101.uu uudecode /usr/src/share/tabset/9837.uu uudecode: stdin: 9837: character out of range: [33-96] *** Error code 1 Stop in /usr/src/share/tabset. Dunno whether the problem is uudecode or tabset. Just fixed it. Update your sources. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rcNg messages
On Thu, 05 Sep 2002 13:17:04 +0200 (CEST)
Harti Brandt [EMAIL PROTECTED] wrote:
rcorder: requirement `ppp' in file `/etc/rc.d/rpcbind' has no providers.
rcorder: requirement `beforenetlkm' in file `/etc/rc.d/ipsec' has no
providers. rcorder: requirement `beforenetlkm' in file `/etc/rc.d/ipfilter'
has no providers. rcorder: requirement `altqd' in file
`/etc/rc.d/NETWORKING' has no providers. rcorder: requirement `dhclient' in
file `/etc/rc.d/NETWORKING' has no providers. rcorder: requirement `network'
in file `/etc/rc.d/NETWORKING' has no providers.
Well, gordon made a commit yesterday to prevent scripts not used by FreeBSD
from being installed. rcorder is complaining because some of those scripts are
in the REQUIRE line of the installed scripts. While your startup order may be
subtly different because of it, it's a benign error message (in this case).
You can redirect it to /dev/null with the following patch.
Cheers,
Mike Makonnen
Index: etc/rc
===
RCS file: /home/ncvs/src/etc/rc,v
retrieving revision 1.317
diff -u -r1.317 rc
--- etc/rc 15 Aug 2002 03:24:47 - 1.317
+++ etc/rc 5 Sep 2002 17:54:32 -
@@ -84,7 +84,7 @@
fi
os=`eval ${CMD_OSTYPE}`
- files=`rcorder -k ${os} -s nostart /etc/rc.d/*`
+ files=`rcorder 2/dev/null -k ${os} -s nostart /etc/rc.d/*`
for _rc_elem in ${files}; do
run_rc_script ${_rc_elem} ${_boot}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvsup10 broken (was: Re: HEADS UP: GCC 3.2.1-pre imported)
Peter Wemm [EMAIL PROTECTED] writes: Don Lewis wrote: It appears that the problem is that cvsup10 is sick. It doesn't have a complete set of the gcc updates. I was only getting rev 1.2 of emit-rtl.c, but rev 1.3 was committed 36 hours ago. I got the correct version of that file plus a bunch of other stuff when I switched to cvsup13. Argh. Out of disk space. Fixing now. This also happened to be the problem for sparc64 tinderbox. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Fatal warnings breaks ipfw on LP64
cc1: warnings being treated as errors /usr/src/sys/netinet/ip_fw2.c: In function `ipfw_ctl': /usr/src/sys/netinet/ip_fw2.c:2508: warning: cast from pointer to integer of different size /usr/src/sys/netinet/ip_fw2.c:2521: warning: cast from pointer to integer of different size Some of the code in question looks questionable: /* * abuse 'next_rule' to store the set_disable word */ (u_int32_t)(((struct ip_fw *)bp)-next_rule) = set_disable; The rvalue is being cast in an assignment to make a pointer store an integer? Surely this can be written better. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Alexander Kabaev [EMAIL PROTECTED] writes: On Mon, 2 Sep 2002 19:51:59 GMT Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: === gnu/usr.bin/cc/cc1plus method.o: In function `use_thunk': method.o(.text+0x90c): undefined reference to `sparc_output_mi_thunk' Is this gcc 3.1 trying to build 3.2 or gcc 3.2 trying to build itself? Buildworld completes fine on panther, the only FreeBSD sparc64 machine I have access to. The complete transcript is available here: http://sparc64.style9.org/sparc64.log Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Alexander Kabaev [EMAIL PROTECTED] writes: The complete transcript is available here: http://sparc64.style9.org/sparc64.log Which still does not answer my question. What GCC version is on this machine? Sorry, I thought your question was whether it was in the cross building stage or later on in the build. %gcc -v Using built-in specs. Configured with: FreeBSD/sparc64 system compiler Thread model: posix gcc version 3.1 [FreeBSD] 20020509 (prerelease) I can provide you with an account on the system. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Peter Wemm [EMAIL PROTECTED] writes: Alexander Kabaev wrote: On Mon, 2 Sep 2002 19:51:59 GMT Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: === gnu/usr.bin/cc/cc1plus method.o: In function `use_thunk': method.o(.text+0x90c): undefined reference to `sparc_output_mi_thunk' Is this gcc 3.1 trying to build 3.2 or gcc 3.2 trying to build itself? Buildworld completes fine on panther, the only FreeBSD sparc64 machine I have access to. This has got to be a local problem, perhaps where src/contrib/sparc/sparc.c is out of sync on the builder machine. This builds fine on panther.freebsd.org. The source directory had some stale copies of files that weren't being updated. I fixed them, so hopefully the next build will work correctly. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Question about device.hints man page
Craig Rodrigues [EMAIL PROTECTED] writes: device.hints.5: $FreeBSD: src/share/man/man5/device.hints.5,v 1.3 2002/08/09 06:07:33 obrien Exp $ I would like to submit the following trivial patch: --- device.hints.5.orig Sun Aug 25 12:52:02 2002 +++ device.hints.5Sun Aug 25 12:52:26 2002 @@ -145,7 +145,7 @@ The following example disables the ACPI driver .Bd -literal -offset indent -hint.acpi.0.disable=1 +hint.acpi.0.disabled=1 .Ed .\ .Pp .\ A control variable may look like: Committed, thanks. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Question about device.hints man page
David O'Brien [EMAIL PROTECTED] writes:
On Sun, Aug 25, 2002 at 12:43:44PM -0400, Mike Barcroft wrote:
Craig Rodrigues [EMAIL PROTECTED] writes:
device.hints.5:
$FreeBSD: src/share/man/man5/device.hints.5,v 1.3 2002/08/09 06:07:33
obrien Exp $
I would like to submit the following trivial patch:
--- device.hints.5.orig Sun Aug 25 12:52:02 2002
+++ device.hints.5Sun Aug 25 12:52:26 2002
@@ -145,7 +145,7 @@
The following example disables the ACPI driver
.Bd -literal -offset indent
-hint.acpi.0.disable=1
+hint.acpi.0.disabled=1
.Ed
.\ .Pp
.\ A control variable may look like:
Committed, thanks.
Uh WAIT! Was this tested?!?
$ grep disable /sys/boot/i386/libi386/i386_module.c
if ((getenv(acpi_load) !getenv(hint.acpi.0.disable))) {
hint.acpi.0.disable=1 certainly did not load the acpi.ko module for me
(as expected by inspecting the code). I'm backing this commit out
someone can prove it is proper.
I checked with sys/dev/acpica/acpi.c:223 to confirm the hint name. I
think one of these two places has it misspelled. Would someone please
fix it or explain why we have differing hints for the seemingly the
same thing?
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: new.
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: Hey... I am new here and just want to check things out for a bit and see if I can't pitch in... At the very least I will try to build CURRENT from time to time and run some programs... maybe somewhere down the road I can commit something worthwhile. I also wanted to see if my filter worked on my email :) Looking forward to working with you all... You might want to get started by reading Michael Lucas' article on testing -current: http://www.onlamp.com/pub/a/bsd/2002/04/18/Big_Scary_Daemons.html Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
why should buildworld touch stuff outside /usr/src ? (was Re:buildworld breakage)
On Fri, 16 Aug 2002 08:55:04 -0400 (EDT) Robert Watson [EMAIL PROTECTED] wrote: I ran into this also, and a bit of fiddling with a debugger was un-enlightening -- it was segfaulting on a write to __collate_substitute_table in parse.y. The pointer to the table didn't appear to be corrupted, and it should have been in writable memory. It also appeared to be properly aligned. I moved on to other stuff but was planning to submit a bug report if it persisted (and therefore wasn't a local nit of mine due to heavy local kernel mods). Ok I just updated to today's sources and it's gone. On the other hand I have another problem now. It seems buildworld touches stuff outside of /usr/src (specifically in /etc/mail). I noticed this behaviour some months ago but promptly forgot about it when I trashed my hard drive and had to rebuild my system. This is the first time since then (May/June) that I have tried running buildworld as a regular user. I would like to be able to continue doing everything short of install as a regular user. Is it really necessary to require root privs to buildworld? [ I've CCed gshapiro ] === usr.sbin/keyserv cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF-c /daemon/bui ld/current/src/usr.sbin/keyserv/keyserv.c cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF-c /daemon/bui ld/current/src/usr.sbin/keyserv/setkey.c cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF-c crypt_svc.c cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF-c /daemon/bui ld/current/src/usr.sbin/keyserv/crypt_server.c cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF -o keyserv ke yserv.o setkey.o crypt_svc.o crypt_server.o -lmp -lcrypto -lrpcsvc gzip -cn /daemon/build/current/src/usr.sbin/keyserv/keyserv.8 keyserv.8.gz === etc === etc/sendmail rm -f freebsd.cf (cd /daemon/build/current/src/etc/sendmail m4 -D_CF_DIR_=/daemon/build/curre nt/src/etc/sendmail/../../contrib/sendmail/cf/ /daemon/build/current/src/etc/s endmail/../../contrib/sendmail/cf/m4/cf.m4 freebsd.mc) freebsd.cf chmod 444 freebsd.cf rm -f /etc/mail/kokeb.ambesa.net.cf (cd /daemon/build/current/src/etc/sendmail m4 -D_CF_DIR_=/daemon/build/curre nt/src/etc/sendmail/../../contrib/sendmail/cf/ /daemon/build/current/src/etc/s endmail/../../contrib/sendmail/cf/m4/cf.m4 /etc/mail/kokeb.ambesa.net.mc) /etc /mail/kokeb.ambesa.net.cf cannot create /etc/mail/kokeb.ambesa.net.cf: permission denied *** Error code 2 Stop in /daemon/build/current/src/etc/sendmail. *** Error code 1 Stop in /daemon/build/current/src/etc. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. Cheers, Mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildworld breakage
I don't know if I'm the only one having this problem, but I haven't been able to make a complete buildworld for a couple of days now. The last time I upgraded was arround August 5. I have been getting a signal 11 consistently in the same spot. === secure/usr.sbin/sshd === share === share/colldef colldef -I /daemon/build/current/src/share/colldef -o bg_BG.CP1251.out /daemon/build/current/src/share/colldef/bg_BG.CP1251.src *** Signal 11 Stop in /daemon/build/current/src/share/colldef. *** Error code 1 Stop in /daemon/build/current/src/share. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: system call accept returning with mutex(s) held
On Thu, Aug 15, 2002 at 01:34:47PM -0400, Robert Watson wrote: | Actually, I've gone ahead and committed the change, update to | uipc_syscalls.c:1.128 and see if the problem goes away. (if you do it by | hand locally, make sure to assign error = EINVAL before jumping). | That did it. Thanks! Mike -- Mike Heffner mheffner@[acm.]vt.edu [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: system call accept returning with mutex(s) held
With -current from earlier this week, panics whenever I start
gaim. Didn't see anything similar in the archives. I'll be happy to
provide more information if needed.
Mounting root from ufs:/dev/ad0s2a
exclusive sleep mutex Giant r = 0 (0xc02da9a0) locked @ ../../../kern/subr_trap.c:80
panic: system call accept returning with mutex(s) held
syncing disks... panic: bremfree: bp 0xc3c32ee4 not locked
Uptime: 3m18s
pfs_vncache_unload(): 1 entries remaining
Dumping 127 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01aaa86 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01aaca3 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc01dfc47 in bremfree (bp=0xc02b0f05) at ../../../kern/vfs_bio.c:633
#4 0xc01e1668 in vfs_bio_awrite (bp=0xc1525840) at ../../../kern/vfs_bio.c:1627
#5 0xc022e991 in ffs_fsync (ap=0xc8e7bc1c) at ../../../ufs/ffs/ffs_vnops.c:231
#6 0xc022df8e in ffs_sync (mp=0xc1471400, waitfor=2, cred=0xc0babe00, td=0xc02d6480)
at vnode_if.h:545
#7 0xc01f162c in sync (td=0xc02d6480, uap=0x0) at ../../../kern/vfs_syscalls.c:129
#8 0xc01aa6a2 in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#9 0xc01aaca3 in panic () at ../../../kern/kern_shutdown.c:493
#10 0xc027d8a2 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135554112, tf_esi = 135604464,
tf_ebp = -1077940868, tf_isp = -924336780, tf_ebx = 673945180, tf_edx = 1, tf_ecx = 0,
tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip = 676290179, tf_cs = 31, tf_eflags =
663, tf_esp = -1077941024, tf_ss = 47}) at ../../../i386/i386/trap.c:1120
#11 0xc026e76d in Xint0x80_syscall () at {standard input}:140
FreeBSD 5.0-CURRENT #1: Wed Aug 14 12:19:54 EDT 2002
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/SATELLIT
E
Preloaded elf kernel /boot/kernel/kernel at 0xc03ff000.
Preloaded elf module /boot/kernel/random.ko at 0xc03ff0a8.
Preloaded elf module /boot/kernel/acpi.ko at 0xc03ff154.
Timecounter i8254 frequency 1193182 Hz
Timecounter TSC frequency 746339059 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (746.34-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x686 Stepping = 6
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR,SSE
real memory = 134086656 (130944K bytes)
avail memory = 125779968 (122832K bytes)
Mike
--
Mike Heffner mheffner@[acm.]vt.edu
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: rcNG and dhcp
On Mon, 12 Aug 2002 12:40:20 +0400 Vladimir B. Grebenschikov [EMAIL PROTECTED] wrote: Hi There is patch to teach rcNG do not try dhcp on not-connected ethernet. simply put ifconfig_fxp0=dhcp-if-carrier into rc.conf It will be interested to somebody Theoretically there are another solution for problem - add new key to dhclient - check interface media before broadcasting. Yes, there is a simple solution: adjust the timeout in dhclient.conf. I will quote David Malone from PR conf/38559: I would have said that it would be a bug not to do DHCP if the interface has been configured for it and might upset people who want to be able to plug the network cable in at a more leasurely pace when they boot their laptops. It also means that dhclient won't be able to use a lease listed in its lease file, even if that lease is valid and the hub/switch/access point you're connected to happens to be temporally down or out of range. I'd suggest that you try reducing the timeouts if the long timeout isn't suitable for your setup. See the timeing options in dhclient.conf man page. Cheers, Mike. -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rcNG and dhcp
On Tue, 13 Aug 2002 20:36:39 +0400 Vladimir B. Grebenschikov [EMAIL PROTECTED] wrote: Yes, there is a simple solution: adjust the timeout in dhclient.conf. It is not solution - it is workaround - I do not wand any dhcp activity if I have no media (say in car) And dhclient in case of failure of detecting network address will install lask seen one, with last seen default gateway and I will get very long timeout while any of my apps will try to reach network instead of instant 'no route to host' Then, bring the interface down manually (it's even easier now that you can insert your own script in the rc boot process). I am not being flippant. Your suggestion, while it solves your problem, would create a problem for others (re-read the quote). Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
Andrew Kolchoogin [EMAIL PROTECTED] writes: David, On Fri, Aug 02, 2002 at 12:39:55AM -0700, David O'Brien wrote: The rest of the GCC using world can use -O2 on their code. We are the only ones that have so much trouble with it. It is probably due to our bugs, not GCC's. sorry, but some time ago I read here that gcc -O2 breaks our printf() in libc. I haven't find any assembler code in /usr/src/lib/libc/stdio/vfprintf.c, as such, if some C compiler can't handle VALID and STANDARDS-COMPLIANT C code, this compiler is broken. Isn't it? Indeed, all of FreeBSD users could help to catch such a bug in gcc optimizer code. :) If someone could find the small segment of code where the optimizer screws up, and write a small program to demonstrate the problem, we would have a good chance of it getting fixed. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- === lib/libc ... /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:88: structure has no member named `highpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:88: structure has no member named `lowpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:116: structure has no member named `highpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:116: structure has no member named `lowpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c: In function `_mcleanup': [...] DES, there wasn't enough context on this to solve the problem. Maybe the URL to the complete log should be appended to the message. I just committed a fix for this problem. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Mike Barcroft [EMAIL PROTECTED] writes: DES, there wasn't enough context on this to solve the problem. I don't really see what more you need. What's missing? The first line and cause of the subsequent errors: In file included from /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:43: /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include/sys/gmon.h:168: syntax error before uintfptr_t Since when I see: /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:86: structure has no member named `lowpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:87: structure has no member named `highpc' ...it doesn't immediately occur to me that the reason those members don't exist is because of a syntax error. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Ah, looks like a bug in whereintheworld. It's not supposed to truncate error messages. I've hacked whereintheworld to print everything since the last '===' in case of an error, rather than just the last ten lines. If anyone is interested it's in ~des/bin on freefall. I've already updated the copy on bowie, so the sparc64 builds should be fine now. Thanks. Do you want to increase the tinderbox to run twice a day? Not many people are using the system since a sparc64 was added to the cluster. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -- Kernel build for GENERIC started on Sat Jul 27 11:45:42 GMT 2002 -- === GENERIC /usr/home/des/tinderbox/sparc64/src/sys/sparc64/conf/GENERIC: unknown option PCI_ENABLE_IO_MODES *** Error code 1 I just committed a fix for this. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -- Kernel build for LINT started on Fri Jul 26 23:27:37 PDT 2002 -- === LINT /local0/scratch/des/src/sys/i386/conf/LINT: unknown option PCI_ENABLE_IO_MODES *** Error code 1 I just committed a fix for this. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -- stage 4: building everything.. -- === usr.sbin/mrouted/testrsrr === usr.sbin/mtest === usr.sbin/mtree === usr.sbin/ndp === usr.sbin/newsyslog === usr.sbin/nfsd /usr/home/des/tinderbox/sparc64/src/usr.sbin/nfsd/nfsd.c: In function `start_server': /usr/home/des/tinderbox/sparc64/src/usr.sbin/nfsd/nfsd.c:836: invalid use of undefined type `struct nfsd_srvargs' /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include/stdio.h: At top level: /usr/home/des/tinderbox/sparc64/src/usr.sbin/nfsd/nfsd.c:84: storage size of `nsd' isn't known *** Error code 1 Looks like Peter fixed this in rev 1.28. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -- Kernel build for GENERIC started on Wed Jul 24 11:45:59 GMT 2002 -- === GENERIC FYI: static unit limits for ppp are set: NPPP=1 Kernel build directory is /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sys/GENERIC Don't forget to do a ``make depend'' ./aicasm: 873 instructions used cc1: warnings being treated as errors /usr/home/des/tinderbox/sparc64/src/sys/kern/uipc_socket.c: In function `soreceive': /usr/home/des/tinderbox/sparc64/src/sys/kern/uipc_socket.c:841: warning: long unsigned int format, different type arg (arg 3) *** Error code 1 I just committed a fix for this. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fxp watchdog timeout patch
Sorry for the delay, here's the patch which should properly implement
watchdog timeout handling in the fxp driver. If you're one of the people
seeing the false watchdog timeout messages, please give this a whirl and
tell me how it worked.
Thanks,
Mike Silby Silbersack
--- if_fxp.cThu Jul 11 23:47:39 2002
+++ /home/silby/if_fxp.cFri Jul 19 00:36:57 2002
-1251,14 +1251,14
txp-mb_head = NULL;
}
sc-tx_queued--;
+ ifp-if_timer = 5;
}
sc-cbl_first = txp;
if (sc-tx_queued == 0) {
ifp-if_timer = 0;
if (sc-need_mcsetup)
fxp_mc_setup(sc);
- } else
- ifp-if_timer = 5;
+ }
/*
* Try to start more packets transmitting.
-1401,7 +1401,10
txp-mb_head = NULL;
}
sc-tx_queued--;
+ ifp-if_timer = 5;
}
+ if (sc-tx_queued == 0)
+ ifp-if_timer = 0;
sc-cbl_first = txp;
/*
* If we haven't received any packets in FXP_MAC_RX_IDLE seconds,
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -- stage 4: building everything.. -- === gnu/lib/libobjc === gnu/lib/libg2c === gnu/usr.bin === gnu/usr.bin/bc === gnu/usr.bin/binutils === gnu/usr.bin/binutils/libiberty === gnu/usr.bin/binutils/libbfd cc1: warnings being treated as errors /usr/home/des/tinderbox/sparc64/src/contrib/binutils/bfd/elf-eh-frame.c: In function `_bfd_elf_discard_section_eh_frame': /usr/home/des/tinderbox/sparc64/src/contrib/binutils/bfd/elf-eh-frame.c:417: warning: comparison between signed and unsigned *** Error code 1 I've reduced the WARNS level in the sparc64 case until David has a chance to look at my patch which fixes this warning. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: different packing of structs in kernel vs. userland ?
Thomas Moestl [EMAIL PROTECTED] writes: Oh, right, that's related: the kernel checks for a minimum size of the passed data on two occasions, first in sooptcopyin(), and then again in check_ipfw_struct(). It the size to be at least sizeof(struct ip_fw), however for structures containing just one action (like the one for the command above) this is again too much in the 64-bit case because of the padding. Can you please try the attached patch (against the CVS version)? Yes, this version works. %%% bowie# ipfw show 00100 0 0 allow ip from me to 192.168.3.1 00200 5484 allow udp from me to 192.168.3.13 00300 0 0 allow tcp from me to 192.168.3.0/24 established 00400 0 0 deny ip from me to 192.168.3.0/24 00500 9734 allow ip from any to any 65535 0 0 deny ip from any to any %%% Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New ipfw isn't 64-bit clean
In struct ip_fw, the member timespace becomes padded with 32-bits because a pointer follows it. This causes the RULESIZE() macro to miscalculate the size of the rule by 4 bytes. Resulting in EINVAL and kernel warnings: %%% bowie# ipfw add allow all from me to 192.168.3.1 0 allow ip from me to 192.168.3.1 ipfw: size mismatch (have 64 want 68) ipfw: getsockopt(IP_FW_ADD): Invalid argument %%% (Shouldn't 0 be 00100?) I worked around the breakage by moving next_rule to the second position in the struct. I imagine the real solution involves not jamming kernel pointers into public interfaces. Also, ipfw(8) has lots of warnings as a result of printf()s with deprecated quad_t's. This should be easily fixed by using intmax_t's. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Bruce Evans [EMAIL PROTECTED] writes: On Thu, 11 Jul 2002, Mike Barcroft wrote: Comments on the attached, untested patch? Disable fatal warnings during bootstrap, build, and cross tools phase of world. The setting of NO_WERROR belongs in [BTX]MAKE if anywhere. This is already done for [BX]MAKE but not for TMAKE. However, I don't like turning off warnings for any of these. Warnings for these stages may be even more important and should be less likely than warnings for building the final world, since it is very important for basic tools to be correct and for their source to be careful about portabilty issues. Well, unfortunately I don't think we can depend on older compilers having correct warnings. In PR 40382, it would seem the 4.5 - HEAD upgrade path is broken because of fatal warnings. A good workaround for that problem might be specifying NO_WERROR for the entire build, in which case -Werror becomes useless anyway. So we might just as well disable early fatal warnings and hope that developers can catch most of the bugs later on in the build. This also has some style bugs :). Any setting of NO_WERROR turns it on, so setting it to different spellings of boolean true is just confusing. It is set correctly for for [BX]MAKE. Oh, that's a much nicer location. :) I think only BMAKE has NO_WERROR defined, not XMAKE. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Peter Wemm [EMAIL PROTECTED] writes: [...] peter@panther[4:22pm]~-106 cc -O -Wformat -c foo.c peter@panther[4:22pm]~-107 ie: it looks like it is completely disabled. Maybe the sparc64 tinderbox host is simply out of sync with -current? It has a kernel/world of June 27, which seems to be the problem. I'll update the system today, but we should probably disable fatal warnings during the build/cross tools phase of world. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Giorgos Keramidas [EMAIL PROTECTED] writes:
Whoever fixes this, and however we agree to fix it,
should also remember to close the bin/40382 PR.
Comments on the attached, untested patch?
Best regards,
Mike Barcroft
Disable fatal warnings during bootstrap, build, and cross tools
phase of world.
Index: Makefile.inc1
===
RCS file: /work/repo/src/Makefile.inc1,v
retrieving revision 1.294
diff -u -r1.294 Makefile.inc1
--- Makefile.inc1 1 Jul 2002 17:51:43 - 1.294
+++ Makefile.inc1 11 Jul 2002 04:50:02 -
@@ -589,8 +589,8 @@
${_cxx_consumers} gnu/usr.bin/texinfo
cd ${.CURDIR}/${_tool}; \
${MAKE} DIRPRFX=${_tool}/ obj; \
- ${MAKE} DIRPRFX=${_tool}/ depend; \
- ${MAKE} DIRPRFX=${_tool}/ all; \
+ ${MAKE} DIRPRFX=${_tool}/ NO_WERROR=true depend; \
+ ${MAKE} DIRPRFX=${_tool}/ NO_WERROR=true all; \
${MAKE} DIRPRFX=${_tool}/ DESTDIR=${MAKEOBJDIRPREFIX} install
.endfor
@@ -624,7 +624,8 @@
.for _tool in bin/csh bin/sh ${_games} gnu/usr.bin/cc/cc_tools ${_fortran} \
${_libroken4} ${_libkrb5} lib/libncurses ${_share} \
usr.bin/awk usr.bin/file usr.sbin/sysinstall
- cd ${.CURDIR}/${_tool}; ${MAKE} DIRPRFX=${_tool}/ build-tools
+ cd ${.CURDIR}/${_tool}; \
+ ${MAKE} DIRPRFX=${_tool}/ NO_WERROR=true build-tools
.endfor
#
@@ -650,8 +651,8 @@
gnu/usr.bin/cc ${_xlint}
cd ${.CURDIR}/${_tool}; \
${MAKE} DIRPRFX=${_tool}/ obj; \
- ${MAKE} DIRPRFX=${_tool}/ depend; \
- ${MAKE} DIRPRFX=${_tool}/ all; \
+ ${MAKE} DIRPRFX=${_tool}/ NO_WERROR=true depend; \
+ ${MAKE} DIRPRFX=${_tool}/ NO_WERROR=true all; \
${MAKE} DIRPRFX=${_tool}/ DESTDIR=${MAKEOBJDIRPREFIX} install
.endfor
Re: gdb errors in world
Erik Greenwald [EMAIL PROTECTED] writes: This may be a stupid question, but is gdbreplay currently broken? I just cvsup'd today (2002-07-08, 18:42 CST (GMT-6)) Yes (unless I missed the fix). Just use NO_WERROR=true for now. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
benign bug in src/sys/kern/kern_resource.c:limcopy() ?
Hello folks, The limcopy() function bcopy()s a struct rlimit, but the len argument to bcopy() is given as sizeof(struct plimit). This hasn't caused any problems so far because the destination address is the first member of struct plimit and all the other member of plimit are initialized immediately thereafter. The patch follows. Cheers, Mike Makonnen Index: sys/kern/kern_resource.c === RCS file: /home/ncvs/src/sys/kern/kern_resource.c,v retrieving revision 1.106 diff -u -r1.106 kern_resource.c --- sys/kern/kern_resource.c29 Jun 2002 02:00:01 - 1.106 +++ sys/kern/kern_resource.c7 Jul 2002 22:01:54 - @@ -811,7 +811,7 @@ MALLOC(copy, struct plimit *, sizeof(struct plimit), M_SUBPROC, M_WAITOK); - bcopy(lim-pl_rlimit, copy-pl_rlimit, sizeof(struct plimit)); + bcopy(lim-pl_rlimit, copy-pl_rlimit, sizeof(struct rlimit)); copy-p_lflags = 0; copy-p_refcnt = 1; return (copy); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: LP64: (int)signal()
Christian Weisgerber [EMAIL PROTECTED] writes:
I would like to clean up the last instances of (int)signal(...) in
the tree. Any objection to the changes below?
Other occurrences not worth touching:
- contrib/opie/opieftpd.c: contrib, not used
- libexec/bootpd/bootpd.c: #ifdef'ed out in favor of sigaction().
Index: atmarpd/atmarpd.c
===
RCS file: /home/ncvs/src/usr.sbin/atm/atmarpd/atmarpd.c,v
retrieving revision 1.4
diff -u -r1.4 atmarpd.c
--- atmarpd/atmarpd.c 9 Dec 2000 09:35:42 - 1.4
+++ atmarpd/atmarpd.c 1 Jul 2002 11:38:07 -
@@ -294,8 +294,7 @@
/*
* Set up signal handlers
*/
- rc = (int)signal(SIGINT, atmarp_sigint);
- if (rc == -1) {
+ if (signal(SIGINT, atmarp_sigint) == SIG_ERR) {
atmarp_log(LOG_ERR, SIGINT signal setup failed);
exit(1);
}
You might want to get rid of the other misuse of `rc' above this and
just remove the variable.
Index: scspd/scspd.c
===
RCS file: /home/ncvs/src/usr.sbin/atm/scspd/scspd.c,v
retrieving revision 1.4
diff -u -r1.4 scspd.c
--- scspd/scspd.c 9 Dec 2000 09:35:42 - 1.4
+++ scspd/scspd.c 1 Jul 2002 11:38:08 -
@@ -319,14 +319,12 @@
/*
* Set up signal handlers
*/
- rc = (int)signal(SIGHUP, scsp_sighup);
- if (rc == -1) {
+ if (signal(SIGHUP, scsp_sighup) == SIG_ERR) {
scsp_log(LOG_ERR, SIGHUP signal setup failed);
exit(1);
}
- rc = (int)signal(SIGINT, scsp_sigint);
- if (rc == -1) {
+ if (signal(SIGINT, scsp_sigint) == SIG_ERR) {
scsp_log(LOG_ERR, SIGINT signal setup failed);
exit(1);
}
[Repeat above sentence.] :)
Otherwise it looks good.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- /bin/sh:Permission denied Oops, this was the result of a conflict with my installworld. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: zero copy code checkin in 2 days, new snapshot
On Mon, 24 Jun 2002, Kenneth D. Merry wrote: On Mon, Jun 24, 2002 at 01:17:03 -0500, Mike Silbersack wrote: On Sun, 23 Jun 2002, Kenneth D. Merry wrote: I'm planning on checking in the zero copy sockets code Tuesday evening, MDT. If there are any concerns, I'm more than willing to delay it. Out of curiousity, what happens when the page being write()n is a mmap'd page shared by multiple processes? Will the page be shared? That could be a big reduction in mbuf cluster usage on some http/ftp systems, I'd guess. The page would be shared, until one of the processes decides to write to it while it is still referenced in the kernel. If that happens, it'll get copied. Ken Cool, thttpd / others should benefit greatly then. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: zero copy code checkin in 2 days, new snapshot
On Mon, 24 Jun 2002, Andre Oppermann wrote: Mike Silbersack wrote: Cool, thttpd / others should benefit greatly then. The last time I checked thttpd didn't even use sendfile(2). It does use accf_http(9). Maybe kqueue(2) could speed it up further. -- Andre I thought that thttpd used kqueue (as of recent versions), and write()s from mmap'd files. I could be wrong, of course. (The program seems to evolve relatively quickly.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rc_ng: amd invocation is still broken
On Mon, 24 Jun 2002 10:54:06 -0700 (PDT)
John Polstra [EMAIL PROTECTED] wrote:
I updated my -current system yesterday, and AMD still isn't being
started quite right by rc_ng. The messages at boot time say:
does the following patch fix it? If so, please commit it.
Cheers,
Mike Makonnen
Index: amd
===
RCS file: /home/ncvs/src/etc/rc.d/amd,v
retrieving revision 1.4
diff -u -r1.4 amd
--- amd 21 Jun 2002 19:50:01 - 1.4
+++ amd 24 Jun 2002 19:10:44 -
@@ -17,8 +17,8 @@
case `${CMD_OSTYPE}` in
FreeBSD)
- start_cmd=echo 'Starting amd.'; /usr/sbin/${name}
start_precmd=amd_precmd
+ command_args=
;;
NetBSD)
command_args='-p -a '$amd_dir' -F /etc/amd.conf /var/run/amd.pid'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: rc_ng apm enable not run
On Fri, 21 Jun 2002 23:25:15 -0700
Mike Makonnen [EMAIL PROTECTED] wrote:
I don't know how I missed /etc/rc.i386 when I was doing the porting.
I'll have a chance to work on it Sunday, unless someone else beats me
to it.
Well, here it is. Let me know how goes it.
Cheers,
Mike Makonnen.
Index: etc/rc.d/apm
===
RCS file: etc/rc.d/apm
diff -N etc/rc.d/apm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ etc/rc.d/apm24 Jun 2002 19:53:06 -
@@ -0,0 +1,30 @@
+#!/bin/sh
+#
+# $FreeBSD: src/etc/rc.d/apmd,v 1.2 2002/06/13 22:14:36 gordon Exp $
+#
+
+# PROVIDE: apm
+# REQUIRE: DAEMON
+# BEFORE: LOGIN
+# KEYWORD: FreeBSD
+
+. /etc/rc.subr
+
+name=apm
+rcvar=`set_rcvar`
+start_precmd=apm_precmd
+command=/usr/sbin/${name}
+command_args=-e enable
+
+apm_precmd()
+{
+ case `${SYSCTL_N} hw.machine_arch` in
+ i386)
+ return 0
+ ;;
+ esac
+ return 1
+}
+
+load_rc_config $name
+run_rc_command $1
Index: etc/rc.d/apmd
===
RCS file: /home/ncvs/src/etc/rc.d/apmd,v
retrieving revision 1.2
diff -u -r1.2 apmd
--- etc/rc.d/apmd 13 Jun 2002 22:14:36 - 1.2
+++ etc/rc.d/apmd 24 Jun 2002 19:54:30 -
@@ -5,14 +5,37 @@
#
# PROVIDE: apmd
-# REQUIRE: DAEMON
+# REQUIRE: DAEMON apm
# BEFORE: LOGIN
+# KEYWORD: FreeBSD NetBSD
. /etc/rc.subr
name=apmd
-rcvar=$name
+rcvar=`set_rcvar`
command=/usr/sbin/${name}
+
+case `${CMD_OSTYPE}` in
+FreeBSD)
+ start_precmd=apmd_prestart
+ ;;
+esac
+
+apmd_prestart()
+{
+case `${SYSCTL_N} hw.machine_arch` in
+i386)
+;;
+ *)
+ return 1
+ ;;
+esac
+
+ # Don't start if apm is already running
+ /etc/rc.d/apm forcestatus 1/dev/null return 1
+
+ return 0
+}
load_rc_config $name
run_rc_command $1
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: zero copy code checkin in 2 days, new snapshot
On Sun, 23 Jun 2002, Kenneth D. Merry wrote: I'm planning on checking in the zero copy sockets code Tuesday evening, MDT. If there are any concerns, I'm more than willing to delay it. Out of curiousity, what happens when the page being write()n is a mmap'd page shared by multiple processes? Will the page be shared? That could be a big reduction in mbuf cluster usage on some http/ftp systems, I'd guess. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rc_ng apm enable not run
On Fri, 21 Jun 2002 18:53:11 +0200 Ronald Klop [EMAIL PROTECTED] wrote: Hello, In the rc_ng is 'apm -e enable' not run if I have apm_enable=YES and/or apmd_enable=YES in my rc.conf. But apmd is run with the last option. uhh... my fault :( I don't know how I missed /etc/rc.i386 when I was doing the porting. I'll have a chance to work on it Sunday, unless someone else beats me to it. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: awk woes
Chris A. Mattingly [EMAIL PROTECTED] writes:
Problem 1:
When running php's configure, awk core dumps several times. I've yet to
determine exactly where the core dumps are occurring, though. Four of
them occur during the configure; but the configure seems to complete OK.
Enable debugging symbols in awk and get a traceback.
Problem 2:
Compiling main/main.c I get the following errors:
main.c: In function `php_disable_functions':
main.c:157: warning: initialization makes pointer from integer without a
cast
main.c:161: warning: assignment makes pointer from integer without a cast
main.c:164: warning: assignment makes pointer from integer without a cast
The relevant lines from main.c are:
154: static void php_disable_functions(TSRMLS_D)
155: {
156:char *func;
157:char *new_value_dup = strdup(INI_STR(disable_functions));
xxx: snip comments
161:func = strtok(new_value_dup, , );
162:while (func) {
163:zend_disable_function(func, strlen(func) TSRMLS_CC);
164:func = strtok(NULL, , );
165:}
166: }
These warnings are indicative of a missing header include. Is
string.h being included?
It's doubtful this is really your problem. Is there any other output
from the compiler?
No other OS's seem to complain about this, so why is freebsd?
Perhaps compiler diagnostics aren't enabled on those systems.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Fixing could sleeep... was (Re: ../../../vm/uma_core.c:132
On Tue, 11 Jun 2002 18:33:32 -0400 (EDT)
John Baldwin [EMAIL PROTECTED] wrote:
Well, it shouldn't be but it is. :-P However, one should try to avoid holding
locks except when necessary to maximize concurrency. Thus it is better to do
things like malloc() and free() while not holding locks if possible.
On which way to go:
I like your idea better, because it is less work and less bloat. Sometimes
I have to keep reminding myself: Choose the simplest design that works.
Fair enough. Thanks for working on this.
np. It's much fun!
I don't know if you recieved my earlier email about a bug that I found in
execve() while working on fixing the malloc w/ process lock held bugs.
Here's a simpler patch.
It fixes possible resource leaks and failure to unlock a lock, introduced
by nectar@ in rev. 1.162 of kern/kern_exec.c, in the case where the call
to fdcheckstd() fails. Basically it fails to deallocate resources and unlock the
process lock.
Cheers,
Mike Makonnen
Index: sys/kern/kern_exec.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.164
diff -u -r1.164 kern_exec.c
--- sys/kern/kern_exec.c7 Jun 2002 05:41:27 - 1.164
+++ sys/kern/kern_exec.c14 Jun 2002 14:06:14 -
@@ -133,7 +133,7 @@
struct image_params image_params, *imgp;
struct vattr attr;
int (*img_first)(struct image_params *);
- struct pargs *oldargs, *newargs = NULL;
+ struct pargs *oldargs=NULL, *newargs = NULL;
struct procsig *oldprocsig, *newprocsig;
#ifdef KTRACE
struct vnode *tracevp = NULL;
@@ -383,8 +383,10 @@
#endif
/* Make sure file descriptors 0..2 are in use. */
error = fdcheckstd(td);
- if (error != 0)
- goto exec_fail_dealloc;
+ if (error != 0) {
+ oldcred = NULL;
+ goto done1;
+ }
/*
* Set the new credentials.
*/
@@ -467,6 +469,7 @@
p-p_args = newargs;
newargs = NULL;
}
+done1:
PROC_UNLOCK(p);
/*
@@ -486,7 +489,8 @@
if (tracevp != NULL)
vrele(tracevp);
#endif
- pargs_drop(oldargs);
+ if (oldargs != NULL)
+ pargs_drop(oldargs);
exec_fail_dealloc:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Sat, 15 Jun 2002 15:18:43 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Otherwise circular dependencies. That's what rcorder(8) is there for. It's not that simple. The most obvious example is the need to use DNS in order to look up syslog hosts, and whether you start syslogd before you start DNS, if DNS needs to syslog errors. Since the DNS information is only used by syslogd when actual logging to a remote host takes place, it should be possible to say that syslog has a soft dependency on DNS, and DNS has a hard dependency on syslog. So, what you're describing is a chicken and egg problem. The solution is simple, the sysadmin decides which one he wants to start first by fiddling with the REQUIRE and BEFORE lines, or the script can make use of the force_depend() subroutine to start required services that aren't already started. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fixing could sleeep... was (Re: ../../../vm/uma_core.c:132
On Sun, 16 Jun 2002 04:10:23 -0700
Mike Makonnen [EMAIL PROTECTED] wrote:
I don't know if you recieved my earlier email about a bug that I found in
execve() while working on fixing the malloc w/ process lock held bugs.
Here's a simpler patch.
It fixes possible resource leaks and failure to unlock a lock, introduced
by nectar@ in rev. 1.162 of kern/kern_exec.c, in the case where the call
to fdcheckstd() fails. Basically it fails to deallocate resources and unlock the
process lock.
embarrased grin
I didn't catch all instances of allocated resources (newargs).
/embarrased grin
Index: sys/kern/kern_exec.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.164
diff -u -r1.164 kern_exec.c
--- sys/kern/kern_exec.c7 Jun 2002 05:41:27 - 1.164
+++ sys/kern/kern_exec.c16 Jun 2002 14:14:37 -
@@ -133,7 +133,7 @@
struct image_params image_params, *imgp;
struct vattr attr;
int (*img_first)(struct image_params *);
- struct pargs *oldargs, *newargs = NULL;
+ struct pargs *oldargs=NULL, *newargs = NULL;
struct procsig *oldprocsig, *newprocsig;
#ifdef KTRACE
struct vnode *tracevp = NULL;
@@ -383,8 +383,10 @@
#endif
/* Make sure file descriptors 0..2 are in use. */
error = fdcheckstd(td);
- if (error != 0)
- goto exec_fail_dealloc;
+ if (error != 0) {
+ oldcred = NULL;
+ goto done1;
+ }
/*
* Set the new credentials.
*/
@@ -467,6 +469,7 @@
p-p_args = newargs;
newargs = NULL;
}
+done1:
PROC_UNLOCK(p);
/*
@@ -476,7 +479,6 @@
crfree(oldcred);
else
crfree(newcred);
- KASSERT(newargs == NULL, (leaking p_args));
/*
* Handle deferred decrement of ref counts.
*/
@@ -486,7 +488,10 @@
if (tracevp != NULL)
vrele(tracevp);
#endif
- pargs_drop(oldargs);
+ if (oldargs != NULL)
+ pargs_drop(oldargs);
+ if (newargs != NULL)
+ pargs_drop(newargs);
exec_fail_dealloc:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Sat, 15 Jun 2002 12:49:52 -0700 Terry Lambert [EMAIL PROTECTED] wrote: David O'Brien wrote: On Fri, Jun 14, 2002 at 03:30:19PM -0700, Terry Lambert wrote: I.e. if REQUIRE describes soft dependency ordering, what describes hard dependency ordering? Why the need to distingish? Otherwise circular dependencies. That's what rcorder(8) is there for. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Fri, 14 Jun 2002 15:30:19 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Ick. What should be used instead of REQUIRE to mean that it will be started? I.e. if REQUIRE describes soft dependency ordering, what describes hard dependency ordering? Correct, the REQUIRE line only describes the dependency ordering. To start it you twiddle the appropriate rc.conf knob. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Sat, 15 Jun 2002 10:44:31 +0930 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: On Thursday, 13 June 2002 at 15:37:55 -0700, Gordon Tetlow wrote: I've imported the excellent work by Mike Makonnen into the tree. Can you summarize what the differences are? o Instead of a few monolithic scripts in /etc there are many task oriented scripts in /etc/rc.d o Dynamic ordering of boot scripts performed at boot o Ability to run a daemon in a jailed environment as a non-privileged user o common subroutines to make scripts shorter and easier to maintain o If necessary, service specific knobs in /etc/rc.conf.d/ Basically, the scripts /etc/rc* scripts have been broken down into individual scripts, each one doing one specific task**. In addition the dependency ordering of the scripts is performed at boot time, so if you have local scripts that you want executed at boot time, it's just a matter of writing up the script, defining what services it should follow (i.e- after local disks have been mounted), and then putting it in /etc/rc.d/. There's a file: /etc/rc.subr, which is intended to make your scripts as short as possible. It contains common subroutines that are useful in writing scripts. Here's a quick introduction: #!/bin/sh # . /etc/rc.subr # PROVIDE: fooservice # REQUIRE: barservice mountcritlocal # KEYWORD: FreeBSD name=foo rcvar=`set_rcvar` command=/usr/bin/foo required_files=/etc/foo.conf load_rc_config $name run_rc_command $1 Given this script, the routines in rc.subr will do the following: o check rc.conf and /etc/rc.conf.d/foo to make sure 'foo_enable' is set. o pull in the correct path to the command if 'foo_command' is specified, and make sure it is executable o check that the required file /etc/foo.conf exists o pull in any command line options specified in the 'foo_flags' variable o if the appropriate variables are defined, start foo in a jail as a non-privileged user. o tell you whether foo is already started o tell you what pid foo is using o let you start foo o let you stop all instances of foo o and some more that I can't think of right now IMO the functionality you get for just those 11 lines is well worth the small effort required in readjusting to this new scheme. If what you want to do requires a little more customization, then you can also define custom start/stop/etc... routines that will be executed instead of the default one. Having said that, there is remarkably little to adjust to. Baring any bugs in the scripts, switching on rcng should not break anything. I have tried to include temporary compatibility shims to ensure that. I had intended to remove them before 5.0-RELEASE, but they should probably be marked as deprecated and instead removed in 6.0-RELEASE. Cheers, Mike Makonnen ** Most scripts do one specific task, but there are exceptions. It is acceptable to do more than one task if they are closely related: for example: /etc/rc.d/sendmail To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Sat, 15 Jun 2002 17:53:03 +0930
Greg 'groggy' Lehey [EMAIL PROTECTED] wrote:
On Saturday, 15 June 2002 at 0:34:36 -0700, Mike Makonnen wrote:
On Sat, 15 Jun 2002 10:44:31 +0930
Greg 'groggy' Lehey [EMAIL PROTECTED] wrote:
On Thursday, 13 June 2002 at 15:37:55 -0700, Gordon Tetlow wrote:
I've imported the excellent work by Mike Makonnen into the tree.
Can you summarize what the differences are?
o Instead of a few monolithic scripts in /etc there are many task oriented
scripts in /etc/rc.d
o Dynamic ordering of boot scripts performed at boot
o Ability to run a daemon in a jailed environment as a non-privileged user
o common subroutines to make scripts shorter and easier to maintain
o If necessary, service specific knobs in /etc/rc.conf.d/
Hmm, appears to be Luke Mewburn's NetBSD stuff, which I know.
Shouldn't there be an Obtained From: NetBSD in the commit messages?
Yes, it is a port of NetBSD's rc sytem as mentioned here:
http://home.pacbell.net/makonnen/rcng.html .
Oversight on Gordon's part I'm sure.
Are you (or is anybody) doing something about keeping as close as
possible to being in sync with NetBSD?
Yeah, when I get some time I'm going to try and get rid of those
case `${CMD_OSTYPE}` clauses together with Luke. David O'Brien said
a while back that he and some others were willing to make sure they stayed
in sync. That's the only reason I made the effort to set it up so that it would
be somewhat easy to do.
Cheers,
Mike Makonnen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Fri, 14 Jun 2002 19:38:15 +0200 Dennis Kristensen [EMAIL PROTECTED] wrote: sendmail_enable=NONE did'nt help either. This can be fixed with below patch. It still complains with /etc/rc: WARNING: $sendmail_enable is not set properly. but sendmail is no longer started. [patch ommited] Thanks. It's supposed to complain to remind me to get together with the sendmail maintainer to figure out how to handle sendmail's non-standard NONE option. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
