Re: X problems using egcs as compiler
* From: David O'Brien obr...@nuxi.com * So the fix we mentioned might not be needed with the base EGCS. Maybe * you can just compile all the ports just to see where we stand. I don't Well, as soon as the first snapshot with the system egcs is released, I'm planning to grab it and run the build through it. The logs will be at the normal place (http://bento/~asami/errorlogs/). -W To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
More on rl0 woes
On the offchance that mty problems were chipset related, I swapped the RealTek with the de0 card in my other machine, a 233MHz k6. It being a socket 7 mboard presumably has a later PCI bios. Still the same symptoms - hangs on NFS access. These can be interrupted and other network traffic continues fine. To reproduce, take your RealTek equipped machine and place a copy of /usr/src on it. Export /usr/src so that it can be NFS mounted by other machines. From the other machines, do an ls -CFR of /usr/src. It will hang partway through. Stephen .e w. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Atime not set on execution ?
Is it normal for atime not to be set on execution of a file ? I should have thought this would class as an access ? (I do not have the filesystem mounted -o noatime :-) This may be questions, but I am running current... Thankyou. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Atime not set on execution ?
Is it normal for atime not to be set on execution of a file ? I should have thought this would class as an access ? It's normal in FreeBSD, although this breaks POSIX.1 conformance. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /var/db/pkg/.mkversion
* From: Jordan K. Hubbard j...@zippy.cdrom.com * As long as that directory is not /var/db/pkg, where I put my package * information, I agree that it doesn't matter either. :-) Ok. I'll move it out then. * I'm not sure that this is a solution so much as a band-aid, however. Of course. It's more of a safety belt, to avoid having people shooting off their own toes. : The real problem is that people try to track ports-current with a release system. There is no solution to that, that's why I'm providing a series of band-aids * I could record the version number of the system as it was when * sysinstall installed it (3.1-RELEASE, X.X-MMDD-CURRENT, etc) but * that's about it. Actually, as you may have read in another message, it seems the problem was caused by a failing install due to to /var/db/pkg missing from the mtree list. Since the release build uses installworld, there really isn't anything special you need to do. * Well, the fetch -A thing was another imprudent leap off the wire * without a net, I'm not sure I'd use it to aid my arguments if I were * you. :-) Aw, touche. But it's no fun leaping if there's a net! -W To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Do you have one?
Some people called the Ricky Willaims Heiman Siloutte shirt, others call it the Dreaded Football Player shirt. UT and the Downtown Athletic Club have tried to ban them through the Collegiate Licensing Company, but unsuccessfully. Thousands of people have got their hands on one of these shirts. We have some as well and are offering you a chance to get yours. This is the exact same shirt that was featured in the Austin American Stateman on December 15, 1998 in the Lifestyles section. Prices are as follows: White shirt with burnt orange siloutte. Sizes are S, M, L, XL, and XXL. XXL's ARE $3.00 MORE!!! 1. $16 +3.20 shipping =$19.20 2. $32 +3.20 shipping =$36.20 3. $48 +4.30 shipping =$52.30 4. $62 +4.30 shipping =$66.30 5. $70 +5.40 shipping =$75.40 Each shirt after 5 shirts is $14.00 each. Please add $1.10 shipping for every 2 shirts over 5 shirts. Burnt orange shirt with white siloutte. Sizes are L, XL, and XXL. XXL's ARE $3.00 MORE!!! 1. $18 +3.20 shipping =$21.20 2. $36 +3.20 shipping =$39.20 3. $52 +4.30 shipping =$56.30 4. $66 +4.30 shipping =$70.30 5. $80 +5.40 shipping =$85.40 Each shirt after 5 shirts is $16.00 each. Please add $1.10 shipping for every 2 shirts over 5 shirts. WE ALSO HAVE 3.5 x 3.5 PEELOUT VINYL STICKERS THAT GO GREAT ON WINDOWS. We will ship one free sticker per tshirt ordered. If you would like extras they are $2 each. Shipping prices reflect US Priority Mail which takes 2-3 day delivery. REMEMBER TO ADD $3.00 IF YOU WANT XXL. IF YOU DO NOT ADD THE $3.00 WE WILL SEND YOU AN XL INSTEAD. Please send check or money order to: JERIMIAH DOWDY PO BOX 2596 AUSTIN, TX 78768 Thank you for your time and have a Happy Easter. PS: If you are still skeptical about this offer, please send a Self Addressed Stamped Envelope along with your email address and/or telephone # and we will contact you to give you more information and a URL. We will not call you if it is long distance, so be sure to send an email address as well. THIS IS LIMITED OFFER! AFTER MAY 1, 1999, WE WILL NOT BE ACCEPTING ANY MORE ORDERS. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
different systat -vmstat output when using egcs to compile kernel
See the leading \n's in the Interrupts column (see !!!) 1st is ok using our cc 2nd is using egcs with different compile options. But error remains the same even with no optimitation kernel compiled with FreeBSD 3.1-STABLE C compiler, -pipe -O 1 usersLoad 0.97 0.39 0.16 So 4 Apr 12:41 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 351804348 3773760 66329000 count All 92160 14304 78560820952 pages 91 cowInterrupts Proc:r p d s wCsw Trp Sys Int Sof Flt430 zfod236 total 1 3 2188 597 909 237 60 582 15516 wire100 clk0 irq2 52868 act 128 rtc0 irq8 5.3%Sys 0.2%Intr 47.6%User 0.0%Nice 47.0%Idl16624 inact pci irq19 |||||||||| 6956 cache 7 pci irq17 === 2044 free 1 pci irq16 daefr atkbd0 irq Namei Name-cacheDir-cache 29 prcfr psm0 irq12 Calls hits% hits% react ed0 irq10 1039 1015 9830 pdwak isic0 irq9 pdpgs Discs ccd0 ccd1 ccd2 ccd3 da0 da1 da2 intrn KB/t 0.00 0.00 5.25 8.00 8.00 4.33 8.00 8345 buf tps 0 0 1 0 4 1 0 7506 desiredvnodes MB/s 0.00 0.00 0.00 0.00 0.03 0.00 0.00 1626 numvnodes 24 freevnodes kernel compiled on FreeBSD 3.1-STABLE with egcs, tried these different compile options ... -mpentiumpro -pipe -O -pipe -O -mpentiumpro -pipe -pipe 1 usersLoad 0.42 0.23 0.09 So 4 Apr 12:51 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 307243976 3736388 6632 11800 count All 92768 11544 73671218172 pages cowInterrupts Proc:r p d s wCsw Trp Sys Int Sof Fltzfod455 total 1 1 22 4072 2533 456 2641 13908 wire243 \nclk0 irq ^^ !!! 53972 act 128 \nrtc0 irq ^^ !!! 9.0%Sys 0.4%Intr 4.3%User 0.0%Nice 86.3%Idl14284 inact \natkbd0 i ^^ !!! |||||||||| 10404 cache84 \npsm0 irq ^^ !!! = 1396 free\ned0 irq1 ^^ !!! daefr \nisic0 ir ^^ !!! Namei Name-cacheDir-cache prcfr Calls hits% hits% react 3831 525 14 1994 52 pdwake pdpgs Discs ccd0 ccd1 ccd2 ccd3 da0 da1 da2 intrn KB/t 0.00 0.00 0.00 0.00 5.07 0.00 0.00 8343 buf tps 0 0 0 086 0 0 7503 desiredvnodes MB/s 0.00 0.00 0.00 0.00 0.42 0.00 0.00 1148 numvnodes 428 freevnodes -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: More on rl0 woes
In message 199904040913.raa26...@ariadne.tensor.pgs.com, `shock...@prth.pgs.com' wrote: On the offchance that mty problems were chipset related, I swapped the RealTek with the de0 card in my other machine, a 233MHz k6. It being a socket 7 mboard presumably has a later PCI bios. Still the same symptoms - hangs on NFS access. These can be interrupted and other network traffic continues fine. To reproduce, take your RealTek equipped machine and place a copy of /usr/src on it. Export /usr/src so that it can be NFS mounted by other machines. From the other machines, do an ls -CFR of /usr/src. It will hang partway through. I have probably same problem here. NFS hangs and other network traffic is still alive. Though, my situation differs a little from yours. I have two RealTek NFS clients and NFS server has another chip. Both of RealTek NFS clients (Celeron 300MHz and MediaGX 266MHz) have the problem. To reproduce: Install bytebench on the RealTek machine. Set env var TMPDIR to somewhere NFS mounted dir. Do bytebench fstime. -- Murata Shuuichirou To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
cvsupped libgcc grief
Well, the troubles continue, after much buggering around with an incorrectly linked cc1 binary, cooked up from I don't know where I ask Is anyone else seeing this kind of error on make buildworld'ing In file included from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/freebsd.h:28, from tm.h:1, from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/xm-i386.h:43, from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/xm-freebsd.h:3, from config.h:1, from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc1.c:35: /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/i386.h:530: syntax error before `,' /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/i386.h:540: warning: no semicolon at end of struct or union cc: Internal compiler error: program cc1 got fatal signal 11 -- [gjvc] FreeBSD-CURRENT -- Because I'm worth it. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: X problems using egcs as compiler
According to Alex Zepeda: Personally, I'd vote for using the new runtime objects, and forcing binary incompatibility. It's worth it IMO for the exception handling support if nothing else. However, if you're dead set against it, just back up your runtime objects, and edit the spec file (like the egcs port forced you to do at one time, and probably still does). The problem I see is that exceptions are for C++ and forcing ANSI C files to be compiled with -fexceptions and linked with new runtime objects is probably not the best way... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: X problems using egcs as compiler
According to David E . O'Brien: src/lib/csu/i386-elf will build and install crtbegin.o and crtend.o from the EGCS sources. Otherwise we have to use the poorer exception unwinding method. Is there a runtime overhead of using these files even for C programs ? -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Make world of 990404 14:20 GMT
Just for the stats: === gnu/lib/libg++/doc === gnu/lib/libgcc cd: can't cd to /work/FreeBSD/src/gnu/lib/libgcc *** Error code 2 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Looking in /usr/src/gnu/lib there's no libgcc directory, yet the Makefile proclaims: [asmo...@daemon] (15) # more Makefile # $Id: Makefile,v 1.20 1999/03/31 06:30:40 obrien Exp $ SUBDIR= libdialog libg++ libgcc libgmp libmp libobjc libregex libreadline libstdc++ .include bsd.subdir.mk Does the libgcc target have to be removed? --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: More on rl0 woes
On the offchance that mty problems were chipset related, I swapped the RealTek with the de0 card in my other machine, a 233MHz k6. It being a I have probably same problem here. NFS hangs and other network traffic is still alive. Though, my situation differs a little from yours. I have two RealTek NFS clients and NFS server has another chip. Both of RealTek NFS clients (Celeron 300MHz and MediaGX 266MHz) have the problem. To reproduce: Install bytebench on the RealTek machine. Set env var TMPDIR to somewhere NFS mounted dir. Do bytebench fstime. heh... i guess I too have similar problems. Though, I've always assumed it was nfs, not the network card. 3coms in the server, realteks in the clients. I've found that inbound traffic on a read-only mount doesn't hang anything. Heavy writes kill me all the time. (Make world for example). To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: different systat -vmstat output when using egcs to compile kernel
On Sun, 4 Apr 1999, Andreas Klemm wrote: See the leading \n's in the Interrupts column (see !!!) 1st is ok using our cc 2nd is using egcs with different compile options. But error remains the same even with no optimitation Very strange. It could have something to do with the following, though, maybe? 1.160 Sun Apr 4 7:11:02 1999 UTC by alc CVS Tags: HEAD Diffs to 1.159 Two changes to vm_map_delete: 1. Don't bother checking object-ref_count == 1 in order to set OBJ_ONEMAPPING. It's a waste of time. If object-ref_count == 1, vm_map_entry_delete will run-down the object and its pages. 2. If object-ref_count == 1, ignore OBJ_ONEMAPPING. Wait for vm_map_entry_delete to run-down the object and its pages. Otherwise, we're calling two different procedures to delete the object's pages. Note: vmstat -s will once again show a non-zero value for pages freed by exiting processes. Also, MAYBE the entire world needs to be compiled by egcs as well to have the correct sizes for structs and such, that might be different. kernel compiled with FreeBSD 3.1-STABLE C compiler, -pipe -O 1 usersLoad 0.97 0.39 0.16 So 4 Apr 12:41 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 351804348 3773760 66329000 count All 92160 14304 78560820952 pages 91 cowInterrupts Proc:r p d s wCsw Trp Sys Int Sof Flt430 zfod236 total 1 3 2188 597 909 237 60 582 15516 wire100 clk0 irq2 52868 act 128 rtc0 irq8 5.3%Sys 0.2%Intr 47.6%User 0.0%Nice 47.0%Idl16624 inact pci irq19 |||||||||| 6956 cache 7 pci irq17 === 2044 free 1 pci irq16 daefr atkbd0 irq Namei Name-cacheDir-cache 29 prcfr psm0 irq12 Calls hits% hits% react ed0 irq10 1039 1015 9830 pdwak isic0 irq9 pdpgs Discs ccd0 ccd1 ccd2 ccd3 da0 da1 da2 intrn KB/t 0.00 0.00 5.25 8.00 8.00 4.33 8.00 8345 buf tps 0 0 1 0 4 1 0 7506 desiredvnodes MB/s 0.00 0.00 0.00 0.00 0.03 0.00 0.00 1626 numvnodes 24 freevnodes kernel compiled on FreeBSD 3.1-STABLE with egcs, tried these different compile options ... -mpentiumpro -pipe -O -pipe -O -mpentiumpro -pipe -pipe 1 usersLoad 0.42 0.23 0.09 So 4 Apr 12:51 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 307243976 3736388 6632 11800 count All 92768 11544 73671218172 pages cowInterrupts Proc:r p d s wCsw Trp Sys Int Sof Fltzfod455 total 1 1 22 4072 2533 456 2641 13908 wire243 \nclk0 irq ^^ !!! 53972 act 128 \nrtc0 irq ^^ !!! 9.0%Sys 0.4%Intr 4.3%User 0.0%Nice 86.3%Idl14284 inact \natkbd0 i ^^ !!! |||||||||| 10404 cache84 \npsm0 irq ^^ !!! = 1396 free\ned0 irq1 ^^ !!! daefr \nisic0 ir ^^ !!! Namei Name-cacheDir-cache prcfr Calls hits% hits% react 3831 525 14 1994 52 pdwake
Re: contrib/egcs
Bernd Rosauer wrote: Hi! I have noticed that egcs-1.1.2 made it into /usr/src/contrib. But 'make buildworld' does not touch it. What is the intended use of egcs? Are you running -current? Are you subscribed to the cvs-all and freebsd-current mailing lists? sarcasm The intended use of egcs ti to compile files. /sarcasm -- Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Bug with afd0 (zip-drive)
Hi, I have the same problems with Soren's new ATA driver: fuchur# mount_msdos -o noauto /dev/afd0s4 /zip mount_msdos: /dev/afd0s4: Invalid argument With the old driver and slice wfd0s4, this worked with msdos formatted zip-mediums. kernel konfig: -- controller ata0 device atadisk0# ATA disk drives device atapicd0# ATAPI CDROM drives device atapifd0# ATAPI floppy drives I've removed the old wdc* controller- and device- options completly. dmesg output with the old driver: - wdc1: unit 1 (atapi): IOMEGA ZIP 100 ATAPI/23.D, removable,intr,iordis wfd0: medium type unknown (no disk) wfd0: buggy Zip drive, 64-block transfer limit set dmesg output with the new driver: - (cvsup from 3 Apr) FreeBSD 4.0-CURRENT #6: Sat Apr 3 17:14:27 CEST 1999 r...@fuchur.lan.attic.ch:/usr/src/sys/compile/FUCHUR ... ... acd0: TOSHIBA CD-ROM XM-6202B/1110 CDROM drive at ata0 as master acd0: drive speed 5512KB/sec, 256KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked afd0: IOMEGA ZIP 100 ATAPI/23.D rewriteable drive at ata0 as slave afd0: 96MB (196608 sectors), 32 cyls, 64 heads, 96 S/T, 512 B/S afd0: Unknown media (0x0) Hi, I'm not able to use msdos disks with afd0. It isn't usable with the mtools too (yes, I've used MAKEDEV to make the needed dev-nodes). cvsup at 7pm CET. not able to use: mdir z: init Z: non DOS media Cannot initialize 'Z:' mount /zip msdos: /dev/afd0s4: Invalid argument Am I missing something? Bye, Alexander. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: More on rl0 woes
On 4 Apr 1999, Murata Shuuichirou wrote: In message 199904040913.raa26...@ariadne.tensor.pgs.com, `shock...@prth.pgs.com' wrote: On the offchance that mty problems were chipset related, I swapped the RealTek with the de0 card in my other machine, a 233MHz k6. It being a socket 7 mboard presumably has a later PCI bios. Still the same symptoms - hangs on NFS access. These can be interrupted and other network traffic continues fine. To reproduce, take your RealTek equipped machine and place a copy of /usr/src on it. Export /usr/src so that it can be NFS mounted by other machines. From the other machines, do an ls -CFR of /usr/src. It will hang partway through. I have probably same problem here. NFS hangs and other network traffic is still alive. Though, my situation differs a little from yours. I have two RealTek NFS clients and NFS server has another chip. Both of RealTek NFS clients (Celeron 300MHz and MediaGX 266MHz) have the problem. To reproduce: Install bytebench on the RealTek machine. Set env var TMPDIR to somewhere NFS mounted dir. Do bytebench fstime. I have a solution and a workaround for you guys, solution: ditch the cheap PoS cards and get an fxp or xl card workaround: switch from UDP to TCP mounts or TCP to UDP, make sure the packet size used for the NFS mounts is a small value, try NFSv3, or if you are already using NFSv3, try NFSv2. Yes, the workaround seems like just try several permutations, but I experianced the same problems, tweaking my NFS mounts, especially to use smaller read/write values made the problem go away. I think that switching to TCP may help. When i got some decent network hardware, my problems went away. -Alfred -- Murata Shuuichirou To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Alfred Perlstein - Admin, coder, and admirer of all things BSD. -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/4.0-current To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: show stopper for EGCS import
Yesterday I changed csu/i386-elf/ to build crtbegin.o and crtend.o from the EGCS source rather than our home-grown ones. ..snip.. I've made the same fix to lib/csu as I did libgcc, but now am getting the same weird install problem Poul-Henning was getting. Well FMH! I found a typo I made in Makefile.inc1. However, there is still a bootstrapping problem related to using the EGCS crtbegin.o/crtend.o. So boys and girls, are are going to use the sjlj-exceptions type exception machanism for a while. THE SWITCH HAS BEEN PULLED! -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: WORM CAM CD
* Kenneth D. Merry | Has the worm driver been taken out of current? | Yes. You have to use cdrecord now for SCSI CD burners. cdrecord lacks support for a whole lot of CD-burners... -- Andreas Dobloug : email: andre...@ifi.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Linuxthreads /usr/src/include/pthread/uthread/pthread.h
Hi,
Linuxthreads (http://lt.tar.com/) is supposed to compile cleanly
against 4.0-current after March 22. (quote from the mentioned web
page)
However, I cvsuped -current on March 31. As the Makefile for the
linuxthreads port contains:
.if !exists(${SRC_BASE}/include/pthread/uthread/pthread.h)
BROKEN= requires pthread.h from /usr/src/include/pthread/uthread
.endif
and this file does not exist, it failed to do a 'make' in
/usr/ports/devel/linuxthreads.
In case it matters: I am actually running 3.1-stable (as of March 25)
and only cvsuped the -current source without making the world. (I do
not really want to switch over to -current if I don't really have to.)
Any ideas about what I am missing here?
Roland
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: show stopper for EGCS import
In article 19990403222515.a75...@nuxi.com, David O'Brien
obr...@nuxi.com wrote:
Yesterday I changed csu/i386-elf/ to build crtbegin.o and crtend.o
from the EGCS source rather than our home-grown ones. This
afternoon I switch my EGCS development machine back to a purely
stock 4.0 SNAPSHOT and found that GCC 2.7.2 cannot compile the new
sources.
I guess if you can't find a better solution, you could always fall
back on a hack like this for crt{begin,end}.c:
#if __GNUC__ 2 || __GNUC__ == 2 __GNUC_MINOR__ = 91
#include egcs version of crt{begin,end}.c
#else
#include gcc version of crt{begin,end}.c
#endif
John
--
John Polstra j...@polstra.com
John D. Polstra Co., Inc.Seattle, Washington USA
Self-interest is the aphrodisiac of belief. -- James V. DeLong
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: show stopper for EGCS import
Cool, What do you mean by: we are going to have to use sjlj-exceptions type exception machanism for a while? Tnks, Amancio Yesterday I changed csu/i386-elf/ to build crtbegin.o and crtend.o from the EGCS source rather than our home-grown ones. ..snip.. I've made the same fix to lib/csu as I did libgcc, but now am getting the same weird install problem Poul-Henning was getting. Well FMH! I found a typo I made in Makefile.inc1. However, there is still a bootstrapping problem related to using the EGCS crtbegin.o/crtend.o. So boys and girls, are are going to use the sjlj-exceptions type exception machanism for a while. THE SWITCH HAS BEEN PULLED! -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: show stopper for EGCS import
On Sun, Apr 04, 1999 at 10:39:15AM -0700, Amancio Hasty wrote: What do you mean by: we are going to have to use sjlj-exceptions type exception machanism for a while? -fsjlj-exceptions is on by default. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: show stopper for EGCS import
On Sun, 4 Apr 1999, David O'Brien wrote: Yesterday I changed csu/i386-elf/ to build crtbegin.o and crtend.o from the EGCS source rather than our home-grown ones. ..snip.. I've made the same fix to lib/csu as I did libgcc, but now am getting the same weird install problem Poul-Henning was getting. Well FMH! I found a typo I made in Makefile.inc1. However, there is still a bootstrapping problem related to using the EGCS crtbegin.o/crtend.o. So boys and girls, are are going to use the sjlj-exceptions type exception machanism for a while. Is there any way to tell gcc not to do this by default, or should I stick to my egcs built from ports (complete with egcs runtime objets) for now? - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: show stopper for EGCS import
Why are exceptions handling on by default better yet do we know why exception handling is not needed by default with gcc-2.8? and has anyone spent time reading the egcs requirements for exception handling? Amancio On Sun, Apr 04, 1999 at 10:39:15AM -0700, Amancio Hasty wrote: What do you mean by: we are going to have to use sjlj-exceptions type exception machanism for a while? -fsjlj-exceptions is on by default. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: show stopper for EGCS import
sjlj-exceptions type exception machanism for a while. Is there any way to tell gcc not to do this by default, Yes, -fno-sjlj-exceptions, but you will proably get core dumps when you throw an exception. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Looks broken to me...
Hi, -- Rebuilding tools needed to build libraries -- [...] === cc_int make: don't know how to make insn-attrtab.c. Stop *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
World Breakage?
In message 19990404093848.a76...@nuxi.com David O'Brien writes: : THE SWITCH HAS BEEN PULLED! cc -O -pipe -DFREEBSD_ELF -I/home/imp/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc -I/home/imp/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/config -DFREEBSD_NATIVE -DDEFAULT_TARGET_VERSION=\egcs-2.91.66\ -DDEFAULT_TARGET_MACHINE=\i386-unknown-freebsd\ -I/usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_tools -I/home/imp/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_tools -I/usr/obj/home/imp/FreeBSD/src/tmp/usr/include -static -o cc gcc.o /usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a /usr/obj/home/imp/FreeBSD/src/tmp/usr/lib/libc.a(mktemp.o): In function `mkstemps': mktemp.o(.text+0x0): multiple definition of `mkstemps' /usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(mkstemp.o)(.text+0x0): first defined here /usr/libexec/elf/ld: Warning: size of symbol `mkstemps' changed from 573 to 39 in mktemp.o I suspect that mkstemp shouldn't be defined in libcc_drv.a. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
Only if you make world with -j x ... without -j it's working. make buildworld -j10 /tmp/build.out 21 breaks the same time making the cc_tools : `gencheck.c' is up to date. `c-parse.in' is up to date. `gencheck.c' is up to date. `c-parse.in' is up to date. === cc_int make: don't know how to make insn-attrtab.c. Stop *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
Hello Bob, Monday, April 05, 1999, 12:03:48 AM, you wrote: BB -- Rebuilding tools needed to build libraries BB -- BB [...] === cc_int BB make: don't know how to make insn-attrtab.c. Stop BB *** Error code 2 BB 1 error BB *** Error code 2 BB 1 error BB *** Error code 2 BB 1 error BB *** Error code 2 BB 1 error BB *** Error code 2 BB 1 error try make clean before building world. but it is seems to be broken anyway: c++ -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe -fno-for-scope -I/usr/src/gnu/usr.bin/groff/libgroff/../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARE_PCLOSE=1 -DHAVE_CC_OSFCN_H=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include -fno-for-scope -I/usr/obj/usr/src/tmp/usr/include -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc -o new.o *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Best regards, Ilyamailto:ca...@avias.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: show stopper for EGCS import
YAY!! David, consider yourself signed up for a six pack of anything you like to drink come the next USENIX. First 6 beers are on me (assuming you don't mind if I pound a 7-up for each beer you drink, that is). :-) - Jordan Yesterday I changed csu/i386-elf/ to build crtbegin.o and crtend.o from the EGCS source rather than our home-grown ones. ..snip.. I've made the same fix to lib/csu as I did libgcc, but now am getting the same weird install problem Poul-Henning was getting. Well FMH! I found a typo I made in Makefile.inc1. However, there is still a bootstrapping problem related to using the EGCS crtbegin.o/crtend.o. So boys and girls, are are going to use the sjlj-exceptions type exception machanism for a while. THE SWITCH HAS BEEN PULLED! -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: WORM CAM CD
Andreas Dobloug wrote... * Kenneth D. Merry | Has the worm driver been taken out of current? | Yes. You have to use cdrecord now for SCSI CD burners. cdrecord lacks support for a whole lot of CD-burners... Oh really? The old Worm driver only supported HP/Philips and Plasmon drives. cdrecord supports those drives, and many more. What CD burner do you have that cdrecord doesn't support? Have you talked to Joerg Schilling about it? Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: More on rl0 woes
Of all the gin joints in all the towns in all the world, Alfred Perlstein had to walk into mine and say: On 4 Apr 1999, Murata Shuuichirou wrote: In message 199904040913.raa26...@ariadne.tensor.pgs.com, `shock...@prth.pgs.com' wrote: On the offchance that mty problems were chipset related, I swapped the RealTek with the de0 card in my other machine, a 233MHz k6. It being a socket 7 mboard presumably has a later PCI bios. Still the same symptoms - hangs on NFS access. These can be interrupted and other network traffic continues fine. To reproduce, take your RealTek equipped machine and place a copy of /usr/src on it. Export /usr/src so that it can be NFS mounted by other machines. From the other machines, do an ls -CFR of /usr/src. It will hang partway through. I have probably same problem here. NFS hangs and other network traffic is still alive. Though, my situation differs a little from yours. I have two RealTek NFS clients and NFS server has another chip. Both of RealTek NFS clients (Celeron 300MHz and MediaGX 266MHz) have the problem. Wait wait wait! You're claiming you have the same problem your configurations are different! He's saying he has a problem when the RealTek card is in the server, and the client is using some other NIC. You're saying you have a problem when the RealTek in the client, and the server is using some other NIC. These are completely different scenarios! I will not allow a bunch of you to all jump on me at the same time claiming you've all got the same problem when you CLEARLY DON'T! EVERYBODY PAY ATTENTION TO WHAT THE OTHER IS SAYING AND WAIT YOUR DAMN TURN OR I'M JUST GOING TO IGNORE THE WHOLE LOT OF YOU AND YOU CAN FIX YOUR OWN DAMN PROBLEMS! I can't believe I'm getting so worked up because you cheap bastards insist on buying the absolute worst network adapter in the world. Go buy an ASIX card for crying out loud. They're cheap, and they actually work worth a damn. Now, as punishment for making me mad, I'm going to address Steven's problem, and the rest of you can just lump it. There are things you should be checking when your problem happens. What does ifconfig rl0 show you? Is the OACTIVE flag set? What does netstat -in say? What does netstat -m say? You say 'traffic continues normally.' This is very confusing: SHOW ME AN EXAMPLE OF WHAT YOU MEAN. When the NFS transfer stops, can you still ping the server host, or do you have to interrupt the transfer and wait for a while before you can communicate with the server again? Can you run tcpdump on the client and observe what happens when the transfer stops? Is the client still sending out read requests? Is the server replying or not? Are the replies garbled? Is there a lot of other activity on the network at the time? Can you initiate another (smaller) NFS transfer when the first one wedges? You have to give me as much information as you can. I need to be able to clearly identify the symptoms of the problem with out all the 'oh my god it doesn't work and I tried this and this and this' crap. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = Mulder, toads just fell from the sky! I guess their parachutes didn't open. = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
c++ -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe -fno-for-scope -I/usr/src/gnu/usr.bin/groff/libgroff/../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARE_PCLOSE=1 -DHAVE_CC_OSFCN_H=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include -fno-for-scope -I/usr/obj/usr/src/tmp/usr/include -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc -o new.o *** Error code 1 Did you get any other output? While ``make'' saw an error, ``c++'' didn't report it for some reason. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
EGCS and Alpha builds
I should mention that ``make world'' on the alpha should be considered totally broken until an Alpha developer can tweak the contrib/egcs/gcc/config/freebsd.h and contrib/egcs/gcc/config/alpha/freebsd*.h bits. I would really like to see contrib/egcs/gcc/config/alpha/freebsd*.h combined into one file. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
Hi, At 9:38 pm +0200 4/4/99, Martin Blapp wrote: Only if you make world with -j x ... without -j it's working. make buildworld -j10 /tmp/build.out 21 breaks the same time making the cc_tools : `gencheck.c' is up to date. `c-parse.in' is up to date. `gencheck.c' is up to date. `c-parse.in' is up to date. === cc_int make: don't know how to make insn-attrtab.c. Stop *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 Looks like you're right. Bit of a bummer if you are running SMP... -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
/usr/obj/home/imp/FreeBSD/src/tmp/usr/lib/libc.a(mktemp.o): In function `mkstemps': mktemp.o(.text+0x0): multiple definition of `mkstemps' /usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(mkstemp.o)(.text+0x0): first defined here /usr/libexec/elf/ld: Warning: size of symbol `mkstemps' changed from 573 to 39 in mktemp.o I can't duplicate this problem. Just to be sure... you aren't using -DNOCLEAN, -O2 or anything like that, right? Would it be possible for you to take the March 31st CURRENT snapshot, do a fresh CVSup/cvs checkout and try a build? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
Only if you make world with -j x ... without -j it's working. OH YES! DON'T -j at this time. I know there are a few dependency problems in the Makefiles at this time. I wanted to do the minimum number of changes to them to get EGCS'ifed. (so cvs diff would be useful) They will be cleaned up once people are successfully doing `make world's. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
In message 19990404132114.c77...@nuxi.com David O'Brien writes:
: I can't duplicate this problem. Just to be sure... you aren't using
: -DNOCLEAN, -O2 or anything like that, right?
:
: Would it be possible for you to take the March 31st CURRENT snapshot, do
: a fresh CVSup/cvs checkout and try a build?
I already have mkstemps in my tree. I had imported it from OpenBSD a
while ago, but hadn't committed it. I'll do that now, as well as
remove the mktemp.c from the offending makefile. It works w/o it and
eliminates an XXX comment.
So you shouldn't be able to reproduce this in a clean tree. :-)
Warner
P.S. here's what I have in my tree that I'll commit soon.
Index: mktemp.c
===
RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/mktemp.c,v
retrieving revision 1.12
diff -d -u -r1.12 mktemp.c
--- mktemp.c1998/10/20 15:33:21 1.12
+++ mktemp.c1999/04/04 19:31:50
@@ -50,29 +50,39 @@
char *_mktemp __P((char *));
-static int _gettemp __P((char *, int *, int));
+static int _gettemp __P((char *, int *, int, int));
int
+mkstemps(path, slen)
+ char *path;
+ int slen;
+{
+ int fd;
+
+ return (_gettemp(path, fd, 0, slen) ? fd : -1);
+}
+
+int
mkstemp(path)
char *path;
{
int fd;
- return (_gettemp(path, fd, 0) ? fd : -1);
+ return (_gettemp(path, fd, 0, 0) ? fd : -1);
}
char *
mkdtemp(path)
char *path;
{
- return(_gettemp(path, (int *)NULL, 1) ? path : (char *)NULL);
+ return(_gettemp(path, (int *)NULL, 1, 0) ? path : (char *)NULL);
}
char *
_mktemp(path)
char *path;
{
- return(_gettemp(path, (int *)NULL, 0) ? path : (char *)NULL);
+ return(_gettemp(path, (int *)NULL, 0, 0) ? path : (char *)NULL);
}
#ifdef UNSAFE_WARN
@@ -88,12 +98,13 @@
}
static int
-_gettemp(path, doopen, domkdir)
+_gettemp(path, doopen, domkdir, slen)
char *path;
register int *doopen;
int domkdir;
+ int slen;
{
- register char *start, *trv;
+ register char *start, *trv, *suffp;
struct stat sbuf;
int pid, rval;
@@ -105,7 +116,13 @@
pid = getpid();
for (trv = path; *trv; ++trv)
;
+ trv -= slen;
+ suffp = trv;
--trv;
+ if (trv path) {
+ errno = EINVAL;
+ return (0);
+ }
while (*trv == 'X' pid != 0) {
*trv-- = (pid % 10) + '0';
pid /= 10;
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
4.0-CURRENT world broken
The FreeBSD 4.0-CURRENT world appears to be broken. The file that appears to be causing the problem is pthread_private.h, included by isatty.c. I can't find anything as to what's causing the breakage _yet_, but I hope to produce a patch today. I CVSup'd only minutes ago. -Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Linuxthreads /usr/src/include/pthread/uthread/pthread.h
Try doing a make buildworld. The .if statement in the linuxthreads
Makefile prevents people from using the wrong version of pthread.h. There is
another pthread.h that pertains to using the Posix threads library.
Carlos C. Tapang
http://www.genericwindows.com
-Original Message-
From: Roland Jesse je...@prinz-atm.cs.uni-magdeburg.de
To: freebsd-current@FreeBSD.ORG freebsd-current@FreeBSD.ORG
Date: Sunday, April 04, 1999 10:32 AM
Subject: Linuxthreads /usr/src/include/pthread/uthread/pthread.h
Hi,
Linuxthreads (http://lt.tar.com/) is supposed to compile cleanly
against 4.0-current after March 22. (quote from the mentioned web
page)
However, I cvsuped -current on March 31. As the Makefile for the
linuxthreads port contains:
.if !exists(${SRC_BASE}/include/pthread/uthread/pthread.h)
BROKEN= requires pthread.h from /usr/src/include/pthread/uthread
.endif
and this file does not exist, it failed to do a 'make' in
/usr/ports/devel/linuxthreads.
In case it matters: I am actually running 3.1-stable (as of March 25)
and only cvsuped the -current source without making the world. (I do
not really want to switch over to -current if I don't really have to.)
Any ideas about what I am missing here?
Roland
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: EGCS and Alpha builds
On Sun, 4 Apr 1999, David O'Brien wrote: I should mention that ``make world'' on the alpha should be considered totally broken until an Alpha developer can tweak the contrib/egcs/gcc/config/freebsd.h and contrib/egcs/gcc/config/alpha/freebsd*.h bits. I would really like to see contrib/egcs/gcc/config/alpha/freebsd*.h combined into one file. I'll try to take a look tomorrow but I have visitors coming so I can't promise anything. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
I get the same error. This is more to the error message which I have included below. I am doing a make buildworld after deleting everything in /usr/obj. Cvsup from freebsd3.freebsd.org at around 21:00 GMT. Jim Bloom bl...@acm.org c++ -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe -fno-for-scope -I/usr/src/gnu/usr.bin/groff/libgroff/../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARE_PCLOSE=1 -DHAVE_CC_OSFCN_H=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include -fno-for-scope -I/usr/obj/usr/src/tmp/usr/include -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc -o new.o In file included from /usr/obj/usr/src/tmp/usr/include/g++/osfcn.h:5, from /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include/posix.h:25, from /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc:24: /usr/obj/usr/src/tmp/usr/include/g++/std.h:23: stddef: No such file or directory *** Error code 1 Stop. David O'Brien wrote: c++ -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe -fno-for-scope -I/usr/src/gnu/usr.bin/groff/libgroff/../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARE_PCLOSE=1 -DHAVE_CC_OSFCN_H=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include -fno-for-scope -I/usr/obj/usr/src/tmp/usr/include -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc -o new.o *** Error code 1 Did you get any other output? While ``make'' saw an error, ``c++'' didn't report it for some reason. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 4.0-CURRENT world broken
The FreeBSD 4.0-CURRENT world appears to be broken. The file that appears to be causing the problem is pthread_private.h, included by isatty.c. You're the only one reporting this problem. Possibly your /usr/obj isn't clean? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
8MB machine hangs in 'newbuf'
I'm trying to install -CURRENT on a 8MB machine, and it invariably seems to hang sooner or later in newbuf. What have we done recently which would screw small-RAM machines ? It seems to run fine on the 0318 SNAP, so that should provide some timeframe... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
WORLD failing in sys/boot/i386
CVSup'd at approx 1100 Pacific time: === sys/boot/i386/boot2 (cd /usr/src/sys/boot/i386/boot2; m4 boot1.m4 boot1.s) | as -o boot1.o ld -nostdlib -static -N -e start -Ttext 0x7c00 -o boot1.out boot1.o objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 2/dev/null cc -elf -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -fno-builtin -O2 -malign-functions=0 -malign-jumps=0 -malign-loops=0 -mrtd -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/boot2/boot2.c (cd /usr/src/sys/boot/i386/boot2; m4 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 sio.s) | as -o sio.o ld -nostdlib -static -N -Ttext 0x1000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x1000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.01 size=6f0 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1520 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e10 text=200 data=1c10 org=0 entry=0 -16 bytes available *** Error code 1 Stop. Scott G. Akmentins-Taylor InterNet: stay...@mrynet.com MRY Systems stay...@idt.net, stay...@mrynet.lv Westlake Village, CA USA (Skots Gregorijs Akmentins-Teilors -- just call me Skots) - Labak miris neka sarkans - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: WORLD failing in sys/boot/i386
At 03:06 PM 4/4/99 +, S. Akmentins-Teilors wrote: CVSup'd at approx 1100 Pacific time: === sys/boot/i386/boot2 (cd /usr/src/sys/boot/i386/boot2; m4 boot1.m4 boot1.s) | as -o boot1.o ld -nostdlib -static -N -e start -Ttext 0x7c00 -o boot1.out boot1.o objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 2/dev/null cc -elf -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -fno-builtin -O2 -malign-functions=0 -malign-jumps=0 -malign-loops=0 -mrtd -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/boot2/boot2.c (cd /usr/src/sys/boot/i386/boot2; m4 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 sio.s) | as -o sio.o ld -nostdlib -static -N -Ttext 0x1000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x1000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.01 size=6f0 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1520 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e10 text=200 data=1c10 org=0 entry=0 -16 bytes available *** Error code 1 I think this was Just fixed, try re-supping and rebuilding Manfred = ||man...@pacbell.net || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 4.0-CURRENT world broken
On Sun, 4 Apr 1999, David O'Brien wrote:
The FreeBSD 4.0-CURRENT world appears to be broken. The file that
appears to be causing the problem is pthread_private.h, included by
isatty.c.
You're the only one reporting this problem. Possibly your /usr/obj isn't
clean?
No, I had the same breakage awhile ago. It comes from old headers
/usr/src/lib/libc_r/uthread/pthread{.h,_np.h} (don't remember where they
come from, but they were there and conflicted with the correct headers
from /usr/src/include).
Removing of those headers has fixed everything
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
===|===
Vladimir Kushnir |
ku...@mail.kar.net, |Powered by FreeBSD
kush...@ap3.bitp.kiev.ua |
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: WORLD failing in sys/boot/i386
At 03:06 PM 4/4/99 +, S. Akmentins-Teilors wrote: CVSup'd at approx 1100 Pacific time: === sys/boot/i386/boot2 (cd /usr/src/sys/boot/i386/boot2; m4 boot1.m4 boot1.s) | as -o boot1.o ld -nostdlib -static -N -e start -Ttext 0x7c00 -o boot1.out boot1.o objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 2/dev/null cc -elf -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -fno-builtin -O2 -malign-functions=0 -malign-jumps=0 -malign-loops=0 -mrtd -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/boot2/boot2.c (cd /usr/src/sys/boot/i386/boot2; m4 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 sio.s) | as -o sio.o ld -nostdlib -static -N -Ttext 0x1000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x1000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.01 size=6f0 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1520 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e10 text=200 data=1c10 org=0 entry=0 -16 bytes available *** Error code 1 I think this was Just fixed, try re-supping and rebuilding Manfred = ||man...@pacbell.net || ||Ph. (415) 681-6235|| = Just CVSup'd, and the only updates were: Connected to cvsup.freebsd.org Updating collection src-all/cvs Edit src/gnu/lib/libgcc/Makefile Edit src/gnu/usr.bin/cc/cc_drv/Makefile Edit src/gnu/usr.bin/cc/cc_tools/Makefile Edit src/lib/libc/stdio/mktemp.c Edit src/sys/kern/kern_ntptime.c Finished successfully I don't see any of this affecting it, but I've started the world again. Lemme know if something there somehow indeed resolves the issue, or if another commit is made. Cheers, -skots -- Scott G. Akmentins-Taylor InterNet: stay...@mrynet.com MRY Systems stay...@idt.net, stay...@mrynet.lv Westlake Village, CA USA (Skots Gregorijs Akmentins-Teilors -- just call me Skots) - Labak miris neka sarkans - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
egcs
I'm busily making world, but in the meantime, what's the name of the system compiler going to be, egcs or gcc, or cc? And the C++ one? +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs
what's the name of the system compiler going to be, egcs or gcc, or cc? And the C++ one? No change in names. cc/gcc and c++/g++/CC -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: WORLD failing in sys/boot/i386
Just CVSup'd, and the only updates were: Try again. It can take an hour or so for changes to make it your favorate CVSup server. The fix is to remove the string `` FreeBSD/i386 BOOT\n'' from src/sys/boot/i386/boot2/boot2.c. The fix is a stopgap messure until the boot2 authors can take a look at it. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 4.0-CURRENT world broken
Vladimir Kushnir ku...@mail.kar.net wrote:
On Sun, 4 Apr 1999, David O'Brien wrote:
The FreeBSD 4.0-CURRENT world appears to be broken. The file that
appears to be causing the problem is pthread_private.h, included by
isatty.c.
You're the only one reporting this problem. Possibly your /usr/obj isn't
clean?
No, I had the same breakage awhile ago. It comes from old headers
/usr/src/lib/libc_r/uthread/pthread{.h,_np.h} (don't remember where they
come from, but they were there and conflicted with the correct headers
from /usr/src/include).
Removing of those headers has fixed everything
Possibly from LinuxThreads changes?
You've got to remember that if you make any local modifications
to the source tree, things are liable to break.
Dan Eischen
eisc...@vigrid.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: egcs
Hi, On Sun, Apr 04, 1999 at 04:02:28PM -0700, David O'Brien wrote: what's the name of the system compiler going to be, egcs or gcc, or cc? And the C++ one? No change in names. cc/gcc and c++/g++/CC Experience says there are a lot of ports which look for egcc and eg++, so it might be nice to add these (and all the other names used for the port) as hardlinks. Won't cost anything (well a few bytes...), and also will help with the depends checking on ports. Regards, -Jeremy -- | I could be anything I wanted to, but one things true --+-- Never gonna be as big as Jesus, never gonna hold the world in my hand |Never gonna be as big as Jesus, never gonna build a promised land |But that's, that's all right, OK with me... -Audio Adrenaline To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs
Experience says there are a lot of ports which look for egcc and eg++, I thought those that do have exlicit CC=egcc and CXX=eg++ in the Makefiles. We will just remove them. so it might be nice to add these (and all the other names used for the port) as hardlinks. Nope. I still want the port around to do comparison testing with the base Egcs. Plus I'm reading a egcs-devel port. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Atime not set on execution ?
Bruce Evans wrote: Is it normal for atime not to be set on execution of a file ? I should have thought this would class as an access ? It's normal in FreeBSD, although this breaks POSIX.1 conformance. Bruce Thanks for the response, there isn't per chance an option to turn this on is there ? I am doing some maintenance on a few machines, and it would be really nice to know when some programs were last run, this seems like the ideal way to do it ? Is this a fault, or has this been done for some good reason ? Is it something I should try and fix ? Thanks for any feedback To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
I've hit this one now too. Jim Bloom bl...@acm.org wrote: I get the same error. This is more to the error message which I have included below. I am doing a make buildworld after deleting everything in /usr/obj. Cvsup from freebsd3.freebsd.org at around 21:00 GMT. Jim Bloom bl...@acm.org c++ -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe -fno-for-scope -I/usr/src/gnu/usr.bin/groff/libgroff/../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARE_PCLOSE=1 -DHAVE_CC_OSFCN_H=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include -fno-for-scope -I/usr/obj/usr/src/tmp/usr/include -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc -o new.o In file included from /usr/obj/usr/src/tmp/usr/include/g++/osfcn.h:5, from /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include/posix.h:2 5, from /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc:2 4: /usr/obj/usr/src/tmp/usr/include/g++/std.h:23: stddef: No such file or directory *** Error code 1 Stop. -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Switch to EGCS
Just succeeded a make world and kernel recompile. A round of applause for David, please ! David: I'm starting with the PPro optimisations on right now. PYD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
I've hit this one now too. I'm trying to duplicate the problem. My guess at the fix is to remove the -DHAVE_CC_OSFCN_H=1\ line from src/gnu/usr.bin/groff/Makefile.cfg. But I can't tell what other problems this may cause. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 4.0-CURRENT world broken
On Sun, 4 Apr 1999, Daniel Eischen wrote:
Vladimir Kushnir ku...@mail.kar.net wrote:
On Sun, 4 Apr 1999, David O'Brien wrote:
The FreeBSD 4.0-CURRENT world appears to be broken. The file that
appears to be causing the problem is pthread_private.h, included by
isatty.c.
You're the only one reporting this problem. Possibly your /usr/obj isn't
clean?
No, I had the same breakage awhile ago. It comes from old headers
/usr/src/lib/libc_r/uthread/pthread{.h,_np.h} (don't remember where they
come from, but they were there and conflicted with the correct headers
from /usr/src/include).
Removing of those headers has fixed everything
Possibly from LinuxThreads changes?
Yes, from some very old port.
You've got to remember that if you make any local modifications
to the source tree, things are liable to break.
Yes, I was bitten a couple of times and now usually run patch on anything
in /usr/src with -b .ctm and keep logs (to have the possibility to at
least fix what I've broken).
Dan Eischen
eisc...@vigrid.com
===|===
Vladimir Kushnir |
ku...@mail.kar.net, |Powered by FreeBSD
kush...@ap3.bitp.kiev.ua |
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
RE: egcs
Besides, I can not imagine the base system is going to track egcs. At some point we will have a newer egcs port and the older system compiler, much as it was before. At least that is my take on things. Tom Veldhouse ve...@visi.com -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org]on Behalf Of Jeremy Lea Sent: Sunday, April 04, 1999 6:11 PM To: David O'Brien Cc: Chuck Robey; freebsd-current@FreeBSD.ORG Subject: Re: egcs Hi, On Sun, Apr 04, 1999 at 04:02:28PM -0700, David O'Brien wrote: what's the name of the system compiler going to be, egcs or gcc, or cc? And the C++ one? No change in names. cc/gcc and c++/g++/CC Experience says there are a lot of ports which look for egcc and eg++, so it might be nice to add these (and all the other names used for the port) as hardlinks. Won't cost anything (well a few bytes...), and also will help with the depends checking on ports. Regards, -Jeremy -- | I could be anything I wanted to, but one things true --+-- Never gonna be as big as Jesus, never gonna hold the world in my hand |Never gonna be as big as Jesus, never gonna build a promised land |But that's, that's all right, OK with me... -Audio Adrenaline To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: different systat -vmstat output when using egcs to compile kernel
Andreas Klemm andr...@klemm.gtn.com wrote: See the leading \n's in the Interrupts column (see !!!) 1st is ok using our cc 2nd is using egcs with different compile options. But error remains the same even with no optimitation ... 1 1 22 4072 2533 456 2641 13908 wire243 \nclk0 irq ^^ !!! I recognize that from gcc-2.8.1: The cpp behaviour changed and resulted in the DEVICE_NAMES macro in vector.h being incorrectly expanded. I suspect the same `bug' is in EGCS. The problem is that cpp (from gcc 2.8.1) _does_not_ remove backslash-newline sequences from string constants (and maybe elsewhere as well). This causes problems with the DEVICE_NAMES macro defined in vector.h and used in vector.s. I have reported this to bug-gcc (in mid-June) but haven't seen any response. At this time, I don't know of any way to disable this - the only work- around is to use a gcc-2.7.x derived cpp (eg the standard cpp). This implies changing NORMAL_S and DRIVER_S in /sys/i386/conf/Makefile.i386 to explicitly use the old (2.7.2.1-derived) cpp in front of as. [Note that according to the GNU as documentation, gas handles backslashes inside strings in the same way as C. This is not (and, according to one of the gas maintainers, has never been) true]. Given that it seems unlikely that we're going to get a fix in either egcs or gas in a hurry, our options appear to be: 1) Keep the gcc2.7.2 cpp around for pre-processing .S 2) switch to m4 (yuk) 3) change config to work around the bug. 4) write a sed (or similar script) to pre-process vector.s Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
This seems to fix the problem. I got all the through buildworld and have installed the code. Man(1) seems to work fine, but I haven't done a major stress test of groff and the related programs. Jim Bloom bl...@acm.org David O'Brien wrote: I've hit this one now too. I'm trying to duplicate the problem. My guess at the fix is to remove the -DHAVE_CC_OSFCN_H=1\ line from src/gnu/usr.bin/groff/Makefile.cfg. But I can't tell what other problems this may cause. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: X problems using egcs as compiler
In article 19990403193632.a55...@titan.klemm.gtn.com,
Andreas Klemm andr...@klemm.gtn.com wrote:
Got the latest egcs port
# $Id: Makefile,v 1.53 1999/03/30 02:58:02 obrien Exp $
Build X11R6 with the following CFLAGS:
-pipe -mpentiumpro -O2
I'm still running X11 and after ,make install' I'm unable
to launch x applications (xterm, ...)
andr...@titan{1001} $ xterm
/usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libXaw.so.6: Undefined symbol
__deregister_frame_info
There are two things going on here. First, I believe you must have
built libXaw.so.6 using egcs, but you must have linked xterm using
the normal system compiler. (Or else you or the Makefile used ld
directly, which is always a bad idea.) If the executable is linked
using egcs, then this error won't happen.
Second, egcs actually contains a hack which attempts to make it work
anyway, even if you linked the program using the old compiler. But
there is a dynamic linker bug (which I just discovered) that prevents
the hack from working. I am testing the fix for that now.
John
--
John Polstra j...@polstra.com
John D. Polstra Co., Inc.Seattle, Washington USA
Self-interest is the aphrodisiac of belief. -- James V. DeLong
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
In article 19990404162457.b78...@nuxi.com, David O'Brien obr...@nuxi.com wrote: I've hit this one now too. I'm trying to duplicate the problem. My guess at the fix is to remove the -DHAVE_CC_OSFCN_H=1\ line from src/gnu/usr.bin/groff/Makefile.cfg. But I can't tell what other problems this may cause. I've been looking into this. The main problem of course is that we're trying to use an old libg++ (and its headers) with a new C++ compiler (and its headers). I think the best fix is to edit src/contrib/libg++/libg++/src/std.h and change #include stddef to #include cstddef. That's the correct name of the file according to the C++ standard. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
I've been looking into this. The main problem of course is that we're trying to use an old libg++ Yes. I think the best fix is to edit src/contrib/libg++/libg++/src/std.h But src/contrib/libg++ src/gnu/lib/libg++ is about to be ``cvs rm''ed. IF we wanted to continue to offer libg++ I would need to import libg++ 2.8.1.3. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
David O'Brien wrote: I think the best fix is to edit src/contrib/libg++/libg++/src/std.h But src/contrib/libg++ src/gnu/lib/libg++ is about to be ``cvs rm''ed. That's even better. :-) IF we wanted to continue to offer libg++ I would need to import libg++ 2.8.1.3. Ick. I'm all for ditching libg++. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: WORLD failing in sys/boot/i386
David O'Brien wrote: Just CVSup'd, and the only updates were: Try again. It can take an hour or so for changes to make it your favorate CVSup server. The fix is to remove the string `` FreeBSD/i386 BOOT\n'' from src/sys/boot/i386/boot2/boot2.c. The fix is a stopgap messure until the boot2 authors can take a look at it. I take the size increase was caused by the compiler replacement? -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org nothing better than the ability to perform cunning linguistics To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: WORLD failing in sys/boot/i386
The fix is to remove the string `` FreeBSD/i386 BOOT\n'' from src/sys/boot/i386/boot2/boot2.c. I take the size increase was caused by the compiler replacement? AFAIK. BTW, there is now a ``-Os'' size optimzation. It includes all -O2 optimizations that don't increase the size + some size-only optimizations. Maybe this is the trick of us? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: different systat -vmstat output when using egcs to compile kernel
: 1 1 22 4072 2533 456 2641 13908 wire243 \nclk0 irq : ^^ !!! : :I recognize that from gcc-2.8.1: The cpp behaviour changed and resulted :in the DEVICE_NAMES macro in vector.h being incorrectly expanded. I :suspect the same `bug' is in EGCS. : :The problem is that cpp (from gcc 2.8.1) _does_not_ remove :backslash-newline sequences from string constants (and maybe elsewhere :as well). This causes problems with the DEVICE_NAMES macro defined in :vector.h and used in vector.s. I have reported this to bug-gcc (in :mid-June) but haven't seen any response. : :At this time, I don't know of any way to disable this - the only work- :around is to use a gcc-2.7.x derived cpp (eg the standard cpp). This :implies changing NORMAL_S and DRIVER_S in /sys/i386/conf/Makefile.i386 :to explicitly use the old (2.7.2.1-derived) cpp in front of as. I suggest using ANSI string constants instead of KR string constants. This is perfectly legal: char *s = abcdefghi; char *s = abc def ghi; char *s = abc def ghi; :Given that it seems unlikely that we're going to get a fix in either :egcs or gas in a hurry, our options appear to be: :1) Keep the gcc2.7.2 cpp around for pre-processing .S :2) switch to m4 (yuk) :3) change config to work around the bug. :4) write a sed (or similar script) to pre-process vector.s : :Peter -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Boot blocks
Just wanted to let people know that the unmodified boot blocks have 144 bytes free if you compile them -Os and -16 free if you compile them -O2. -fno-exceptions didn't seem to impact things at all, nor did -fno-sjlj-exceptions. At least in terms of size. So it looks like the right fix for the boot blocks is to use -Os rather than -O2. This will make them slightly slower, but no body[*] is going to be able to convince me that they can measure the difference. Warner [*] With the possible exception of Bruce. :-) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SMP users (important)
:On Fri, 2 Apr 1999, Alan Cox wrote: : : Now, if you're not using Luoqi's patches to enable multithreaded : address spaces, you can stop reading here. If you are, you'll : need to patch i386/i386/swtch.s as follows: : :My suggestion is that we apply Luoqi's %fs patch to -current rather than :have to track these changes manually.. : :Luoqi? Have you had any -ve feedback on this? : :(and what would be the equivalent ALPHA patch?) :I can imagine the original PDE trick working on the alpha but :they don't have a spare register sitting around.. : :julian I'd like to see this too. I will soon have two SMP boxes of my own to play with for my own personal use and for an upcoming project, and at least one will be available for SMP life-testing purposes for several months. I really want to see two things: (1) Actual sharing of the physical pmap between rfork(RFMEM|RFPROC)'d processes, and (2) Avoiding the %cr3 reload ( which clears the TLB ) when switching between such processes. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
