libstdc++ is broken
Best described in gnu/10956, libstdc++ has strange undefined reference errors when compiling anything C++. These are the errors: /usr/lib/libstdc++.so: undefined reference to `filebuf virtual table' /usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table' Please consult the pr for more information. Thanks! Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SMP users (important)
On Sun, 4 Apr 1999, Matthew Dillon wrote: :(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.. do they? : :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. This would also suggest shceduler changes that would increasr the likelyhood of 'related' processes being scheduled together. One scheme I remember id the A-list/B-list scheme, where each scheduling priority has two list that are alternated. whichever list is being drained is not eligible for receiving new items. They must go to the other list. When the active list is drained and theya are switched, the new list is first sorted accoring to affinity related effects. julian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 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. Were you able to actually boot the bootblocks compiled with EGCS and -Os ? (I know the optimization gives us the space we need, but I'm not upto testing new bootblocks at this moment) -- -- 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: egcs
What will become of f77 which is in src/gnu/usr.bin/cc/f77? This seems to be a good time to decide what will happen with Fortran in the base FreeBSD system. VERY good question. I have no opinion in the matter, but will follow the wishes of others (or Core, or committers, or who ever should make this decision and who ever tells me which way to go). -- -- 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: egcs
David O'Brien wrote: What will become of f77 which is in src/gnu/usr.bin/cc/f77? This seems to be a good time to decide what will happen with Fortran in the base FreeBSD system. VERY good question. I have no opinion in the matter, but will follow the wishes of others (or Core, or committers, or who ever should make this decision and who ever tells me which way to go). My take on this is that it could be a lot more difficult to make as a port than as a SUBDIR+= ? My (non-binding and unemotional) vote is for Fortran to be in the base system. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs
David O'Brien wrote: What will become of f77 which is in src/gnu/usr.bin/cc/f77? This seems to be a good time to decide what will happen with Fortran in the base FreeBSD system. VERY good question. I have no opinion in the matter, but will follow the wishes of others (or Core, or committers, or who ever should make this decision and who ever tells me which way to go). My preference is to have g77 as part of the base egcs in the tree, and if we need f77 (ie: the Fortran-C translator), port-ify it since it is easily made standalone while g77 isn't. The sticky bit is what how to handle libI77 and libF77.. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Boot blocks
In article 199904050513.xaa69...@harmony.village.org, Warner Losh i...@harmony.village.org wrote: -fno-exceptions didn't seem to impact things at all, nor did -fno-sjlj-exceptions. At least in terms of size. That's because the default for C programs is -fno-exceptions. That option still should be added to the Makefiles for boot in such a way as to override a possible -fexceptions in /etc/make.conf. When there are conflicting options, the last one wins. 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: different systat -vmstat output when using egcs to compile kernel
Matthew Dillon dil...@apollo.backplane.com wrote: :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 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; Currently we have something like: #define DEVICE_NAMES \ clk0 irqnn\0\ rtc0 irqnn\0\ pci irqnn\0\ pci irqnn\0\ pci irqnn\0\ .ascii DEVICE_NAMES Which expands and assembles into something like: 20: 5c 6e 63 6c 6b 30 20 69 72 71 6e 6e 00 5c 6e 72 |\nclk0 irqnn.\nr| 30: 74 63 30 20 69 72 71 6e 6e 00 5c 6e 70 63 69 20 |tc0 irqnn.\npci | 40: 69 72 71 6e 6e 00 5c 6e 70 63 69 20 69 72 71 6e |irqnn.\npci irqn| Surprisingly, ANSI-C string concatenation _does_ work in gas, so the following works correctly: #define DEVICE_NAMES \ clk0 irqnn\0 \ rtc0 irqnn\0 \ pci irqnn\0 \ pci irqnn\0 \ pci irqnn\0 .ascii DEVICE_NAMES This suggests that what's needed is a patch to config to make it generate ANSI strings. The following (untested) patch should do it: Index: mkglue.c === RCS file: /home/CVSROOT/./src/usr.sbin/config/mkglue.c,v retrieving revision 1.14 diff -u -r1.14 mkglue.c --- mkglue.c1998/04/02 04:25:39 1.14 +++ mkglue.c1999/04/05 08:31:55 @@ -368,17 +368,17 @@ fprintf(fp, * Macros for interrupt vector routines\n); fprintf(fp, * Generated by config program\n); fprintf(fp, */\n\n); - fprintf(fp, #define\tDEVICE_NAMES n); - fprintf(fp, clk0 irqnn\\0\\\n); - fprintf(fp, rtc0 irqnn\\0\\\n); - fprintf(fp, pci irqnn\\0\\\n); - fprintf(fp, pci irqnn\\0\\\n); - fprintf(fp, pci irqnn\\0\\\n); - fprintf(fp, pci irqnn\\0\\\n); - fprintf(fp, ipi irqnn\\0\\\n); - fprintf(fp, ipi irqnn\\0\\\n); - fprintf(fp, ipi irqnn\\0\\\n); - fprintf(fp, ipi irqnn\\0\\\n); + fprintf(fp, #define\tDEVICE_NAMES \\\n); + fprintf(fp, \clk0 irqnn\\0\ \\\n); + fprintf(fp, \rtc0 irqnn\\0\ \\\n); + fprintf(fp, \pci irqnn\\0\ \\\n); + fprintf(fp, \pci irqnn\\0\ \\\n); + fprintf(fp, \pci irqnn\\0\ \\\n); + fprintf(fp, \pci irqnn\\0\ \\\n); + fprintf(fp, \ipi irqnn\\0\ \\\n); + fprintf(fp, \ipi irqnn\\0\ \\\n); + fprintf(fp, \ipi irqnn\\0\ \\\n); + fprintf(fp, \ipi irqnn\\0\ \\\n); dev_id = 10; vector_devtab(fp, bio, dev_id); vector_devtab(fp, tty, dev_id); @@ -386,7 +386,7 @@ vector_devtab(fp, cam, dev_id); vector_devtab(fp, ha, dev_id); vector_devtab(fp, null, dev_id); - fprintf(fp, \\n\n); + fprintf(fp, \n); fprintf(fp, #define\tNR_DEVICES\t%d\n, dev_id); (void) fclose(fp); moveifchanged(path(vector.h.new), path(vector.h)); @@ -406,7 +406,7 @@ mp = dp-d_conn; if (mp == NULL || mp == TO_NEXUS || !eq(mp-d_name, isa)) continue; - fprintf(fp, %s%d irqnn\\0\\\n, dp-d_name, dp-d_unit); + fprintf(fp, \%s%d irqnn\\0\ \\\n, dp-d_name, dp-d_unit); (*dev_idp)++; } } Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
gnu/usr.bin/genclass
genclass has GPPDIR=${BLA}/libg++ in its Makefile breaking the make
world, not sure if you noticed already, didn't see a commit message
about it :-)
Mark
--
Nice testing in little China...
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Boot blocks
On 05-Apr-99 David O'Brien wrote: 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. Were you able to actually boot the bootblocks compiled with EGCS and -Os ? (I know the optimization gives us the space we need, but I'm not upto testing new bootblocks at this moment) Funny thing is that I get an option unknown: -Os when trying that solution. A -O instead of -O2 however solves my problem and leaves me with 188 bytes free. Guess that means that my make world still uses (g)cc offcourse as it does not recognise the -Os flag. --- 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: Boot blocks
On 05-Apr-99 Jeroen Ruigrok/Asmodai wrote: On 05-Apr-99 David O'Brien wrote: 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. Were you able to actually boot the bootblocks compiled with EGCS and -Os ? (I know the optimization gives us the space we need, but I'm not upto testing new bootblocks at this moment) Funny thing is that I get an option unknown: -Os when trying that solution. A -O instead of -O2 however solves my problem and leaves me with 188 bytes free. Guess that means that my make world still uses (g)cc offcourse as it does not recognise the -Os flag. Hmmm, hate to return on my own messages, but this is funny: set -Os in make.conf and compiled everything with it, yet the bootblocks don't like that option. In the meantime I changed -O2 to -O in the boot2/Makefile Something I missed here? --- 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: WORM CAM CD
As 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... ? Having just a while ago downloaded the latest cdrecord source I'd say the list of supported hardware for cdrecord is a helluvalot longer than the worm stuff ever had. Groeten / Cheers, Wilko _ __ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl ___ Powered by FreeBSD ___ http://www.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
As 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. THE SWITCH HAS BEEN PULLED! FWIW, my Aspen Alpine AXP doing a buildworld on freshly (this afternoon) supped -current: . === etc/sendmail rm -f freebsd.cf (cd /usr/src/etc/sendmail m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/ sendmail/cf/ /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 freebsd.mc ) freebsd.cf chmod 444 freebsd.cf 16293.67 real 12302.28 user 3910.24 sys Buildworld seems to work fine on the alpha port. Congrats I'd say. Groeten / Cheers, Wilko _ __ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl ___ Powered by FreeBSD ___ http://www.freebsd.org _ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
CPP broken on egcs current
A make buildworld fails on an freshly rebuilt system. The following error is shown: -- Rebuilding /usr/include -- cd /usr/source/src; SHARED=copies PATH=/usr/obj/usr/source/src/tmp/sbin:/usr/obj /usr/source/src/tmp/usr/sbin:/usr/obj/usr/source/src/tmp/bin:/usr/obj/usr/source /src/tmp/usr/bin:/home/paulz/bin:/home/paulz/bin/trantor.xs4all.nl:/usr/local/bi n:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/games:/sbin:/bin:/usr/l ocal/jdk1.1.7/bin:/usr/local/pilot/bin:/usr/local/pgsql/bin BISON_SIMPLE=/usr/ob j/usr/source/src/tmp/usr/share/misc/bison.simple COMPILER_PATH=/usr/obj/usr/sou rce/src/tmp/usr/libexec:/usr/obj/usr/source/src/tmp/usr/bin GCC_EXEC_PREFIX=/us r/obj/usr/source/src/tmp/usr/lib:/usr/obj/usr/source/src/tmp/usr/lib/ LD_LIBRAR Y_PATH=/usr/obj/usr/source/src/tmp/usr/lib LIBRARY_PATH=/usr/obj/usr/source/src /tmp/usr/lib:/usr/obj/usr/source/src/tmp/usr/lib NOEXTRADEPEND=t OBJFORMAT_PATH =/usr/obj/usr/source/src/tmp/usr/libexec:/usr/libexec /usr/obj/usr/source/src/tm p/usr/bin/make DESTDIR=/usr/obj/usr/source/src/tmp -f Makefile.inc1 includes cd /usr/source/src/include; /usr/obj/usr/source/src/tmp/usr/ bin/make -B all install creating osreldate.h from newvers.sh setvar PARAMFILE /usr/source/src/include/../sys/sys/param.h; . /usr/source/src/ include/../sys/conf/newvers.sh; echo $COPYRIGHT osreldate.h ;echo \#'undef __FreeBSD_version' osreldate.h; echo \#'define __FreeBSD_version' $RELDATE osreldate.h === rpcsvc rpcgen -C -h -DWANT_NFS3 /usr/source/src/include/rpcsvc/key_prot.x -o key_prot.h /usr/source/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:1882: Int ernal compiler error in function main *** Error code 33 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. I get the same internal error when xrdb tries to run my .Xresources file thru CPP so does xdm trying the run Xresources thru cpp.. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
arp.
I have to add a gateway to my net for experimental reasons. Actually there are : a main-router that works as interface to the Internet, and some hosts on my sub net. Internet-MyRouterMySubNet NOw i need to configure one host of MYSubNet to act as a gatway for the secondary subnet. Both the 1SubNet and 2 SubNEt share the same ip-range. Internet-MyRouterMySubNet-My2SubNet All the sub.net have to be seen from the Internet so I'll need to add a route to MainRouter in order to route the Secondary Subnet. The problem is that i cannot change configuration of the mainroute,so i wonder if is possible to configure the new gateway to do a sort of proxy arp for my secondary Subnet. But arp-tables are system-wide so if i change arp entry to cacth request on PrimaryNet the 2subnet dont'works anymore. Is possible to catch arp request only on a single subnet,without broke any other subnet connected to the same host.? thank you! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Success!
OK, make world completed ok. Even rebooted to test the bootblocks (see previous messages) and all is well. Well, sorta, lotsa errors when trying to make a new kernel, fonts are fuqed, Window Maker all of a sudden acts weird with its general menu, ppp gives an ioctl error... This might mean that people runnin CURRENT might have to recompile a lot of things. Suggestions, hints, tips, advice? =) --- 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: show stopper for EGCS import
What does 'cc -v' show on your system? I just finished a 'make world' on
mine, and it still says 2.7.2.1 ... am I missing something here? :(
On Sun, 4 Apr 1999, Wilko Bulte wrote:
As 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.
THE SWITCH HAS BEEN PULLED!
FWIW, my Aspen Alpine AXP doing a buildworld on freshly (this afternoon)
supped -current:
.
=== etc/sendmail
rm -f freebsd.cf
(cd /usr/src/etc/sendmail m4
-D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/
sendmail/cf/ /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4
freebsd.mc
) freebsd.cf
chmod 444 freebsd.cf
16293.67 real 12302.28 user 3910.24 sys
Buildworld seems to work fine on the alpha port. Congrats I'd say.
Groeten / Cheers,
Wilko
_ __
| / o / / _ Arnhem, The Netherlands
|/|/ / / /( (_) BulteWWW :
http://www.tcja.nl
___ Powered by FreeBSD ___ http://www.freebsd.org _
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: arp.
At 12:22 pm +0100 5/4/99, andrea wrote: I have to add a gateway to my net for experimental reasons. Actually there are : a main-router that works as interface to the Internet, and some hosts on my sub net. Internet-MyRouterMySubNet NOw i need to configure one host of MYSubNet to act as a gatway for the secondary subnet. Both the 1SubNet and 2 SubNEt share the same ip-range. Internet-MyRouterMySubNet-My2SubNet All the sub.net have to be seen from the Internet so I'll need to add a route to MainRouter in order to route the Secondary Subnet. The problem is that i cannot change configuration of the mainroute,so i wonder if is possible to configure the new gateway to do a sort of proxy arp for my secondary Subnet. But arp-tables are system-wide so if i change arp entry to cacth request on PrimaryNet the 2subnet dont'works anymore. Is possible to catch arp request only on a single subnet,without broke any other subnet connected to the same host.? thank you! Assuming that these are IP routers and not ethernet switches, the arp tables aren't particularly relevent. If the main router is running 'routed' or some other RIP routing daemon, all you need to do is run a similar daemon and your new subnet route will be propagated. Alternatively, or essentially if you are using unregistered IP, you could use 'natd' on 'MyRouter' to masquerade the internal addresses onto the external interface. The handbook pages on natd make it very easy to set up. Good luck Robin. -- Robin Melville, Addiction Information Services Nottingham Alcohol Drug Team Tel: +44 (0)115 952 9478 Fax: +44 (0)115 952 9421 work: rob...@nadt.org.ukhome: rob...@innotts.co.uk Pages: http://www.innotts.co.uk/~robmel(home page) http://www.innotts.co.uk/nadt (substance misuse pages) -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
C++
OK,
we're coming a long way David, but the thing for which egcs was chosen
doesn't quite work according to autoconf:
checking for gcc... cc
checking whether the C compiler (cc -Os -pipe ) works... yes
checking whether the C compiler (cc -Os -pipe ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether cc accepts -g... yes
checking for c++... c++
checking whether the C++ compiler (c++ ) works... no
configure: error: installation or configuration problem: C++ compiler
cannot create executables.
*** Error code 1
That's the www/libwww port.
Here's the config.log which might help ye troubleshoot c++:
configure:1285: checking for c++
configure:1317: checking whether the C++ compiler (c++ ) works
configure:1333: c++ -o conftestconftest.C 15
/usr/lib/libstdc++.so: undefined reference to `filebuf virtual table'
/usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table'
configure: failed program was:
#line 1328 configure
#include confdefs.h
int main(){return(0);}
Keep going mate, we're coming closer =)
---
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: show stopper for EGCS import
Mine shows: Using builtin specs. gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) Everything is well. I haven't tried out C++ yet though. Tom Veldhouse ve...@visi.com -Original Message- From: The Hermit Hacker scra...@hub.org To: Wilko Bulte wi...@yedi.iaf.nl Cc: obr...@nuxi.com obr...@nuxi.com; curr...@freebsd.org curr...@freebsd.org Date: Monday, April 05, 1999 6:52 AM Subject: Re: show stopper for EGCS import What does 'cc -v' show on your system? I just finished a 'make world' on mine, and it still says 2.7.2.1 ... am I missing something here? :( To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
egcs c++ problems
I get the following when trying to build the following very simple C++ test:
// begin program
#include iostream
using namespace std;
int main(int argc, char** argv) {
cout Hello World!!!\n endl;
return 0;
}
// end program
c++ foobar.cc -o foobar
/usr/lib/libstdc++.so: undefined reference to `filebuf virtual table'
/usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table'
Are there any parts of world that are going to have a hard time building under
egcs because of this?
Tom Veldhouse
ve...@visi.com
Re: egcs c++ problems
Thomas T. Veldhouse wrote: Are there any parts of world that are going to have a hard time building under egcs because of this? There would be if it had stay like that... the last changes from David : cvs commit: src/gnu/lib/libstdc++/doc Makefile Date: Mon, 5 Apr 1999 03:21:31 -0700 (PDT) fix it. I just recompiled your program with the new libstdc++.so.3, and it's fine. PYD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: show stopper for EGCS import
Hrmmm...have to try that again tonight whenI get home then...maybe I
cvsup'd a snapshot just before it got updated :(
On Mon, 5 Apr 1999, Thomas T. Veldhouse wrote:
Mine shows:
Using builtin specs.
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
Everything is well. I haven't tried out C++ yet though.
Tom Veldhouse
ve...@visi.com
-Original Message-
From: The Hermit Hacker scra...@hub.org
To: Wilko Bulte wi...@yedi.iaf.nl
Cc: obr...@nuxi.com obr...@nuxi.com; curr...@freebsd.org
curr...@freebsd.org
Date: Monday, April 05, 1999 6:52 AM
Subject: Re: show stopper for EGCS import
What does 'cc -v' show on your system? I just finished a 'make world' on
mine, and it still says 2.7.2.1 ... am I missing something here? :(
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
make -jn ?
World builds OK here now, kernel, bootblocks and all. Good job! Is `make -jn' safe yet? Could turn these test builds round a lot faster :-) -- 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
Make world Broken on my machine
What am I doing wrong here, this is my error, CVSup was run 10 minutes ago. cc -O -pipe -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/objc -DFREEBSD_ELF -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc - I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/config -DFREEBSD_ NATIVE -DDEFAULT_TARGET_VERSION=\egcs-2.91.66\ -DDEFAULT_TARGET_MACHINE=\i386 -unknown-freebsd\ -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr /src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c In file included from /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/ gcc/config/i386/xm-i386.h:43, from /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/ gcc/hconfig.h:2, from /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/ gcc/gengenrtl.c:22: /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/tm.h:3: linux.h: N o such file or directory /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/tm.h:4: i386/freeb sd-elf.h: No such file or directory *** Error code 1 Stop. with a bunch more of the error code 1 and Stop. can someone help? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Atime not set on execution ?
On Mon, 05 Apr 1999 08:46:38 +0930, Ian West i...@apdata.com.au said: Thanks for the response, there isn't per chance an option to turn this on is there ? The way programs are executed (by intention) does not run through the code path which would touch the access time. The POSIX.1 specification, IIRC, requires that the atime be updated when the program exits -- this would be very inefficient to do in our VM system. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
On 04-Apr-99 David O'Brien wrote: /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(mks temp.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? I now can =) using a freshly cvsupped repository, cvs checkout of src, and make with a clean obj tree. So -DNOCLEAN isn't the issue, I replace -O2 in the /etc/make.conf with -Os. Funny thing that it bombs now, whereas I made world fine before. === gnu/usr.bin/cc/cc cc -Os -pipe -DFREEBSD_ELF -I/work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc -I/work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/config -DFREEBSD_NATIVE -DDEFAULT_TARGET_VERSION=\egcs-2.91.66\ -DDEFAULT_TARGET_MACHINE=\\ -I/usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_tools -I/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_tools -c /work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/gcc.c In file included from /work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/gcc.c:555: /usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_tools/multilib.h:4: warning: initialization from incompatible pointer type /work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/gcc.c:1178: warning: initialization from incompatible pointer type /work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/gcc.c: In function `print_multilib_info': /work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/gcc.c:5919: warning: assignment from incompatible pointer type cc -Os -pipe -DFREEBSD_ELF -I/work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc -I/work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/config -DFREEBSD_NATIVE -DDEFAULT_TARGET_VERSION=\egcs-2.91.66\ -DDEFAULT_TARGET_MACHINE=\\ -I/usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_tools -I/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_tools-o cc gcc.o /usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a /usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(choose-tem p.o): In function `make_temp_file': choose-temp.o(.text+0x278): undefined reference to `mkstemps' *** Error code 1 Stop. Going to look at Warner's patches just in case... --- 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: egcs
Peter Wemm wrote:
David O'Brien wrote:
What will become of f77 which is in src/gnu/usr.bin/cc/f77? This
seems to be a good time to decide what will happen with Fortran in the
base FreeBSD system.
VERY good question. I have no opinion in the matter, but will follow the
wishes of others (or Core, or committers, or who ever should make this
decision and who ever tells me which way to go).
My preference is to have g77 as part of the base egcs in the tree, and if
we need f77 (ie: the Fortran-C translator), port-ify it since it is easily
made standalone while g77 isn't.
I already have a port of f2c and a new f77 wrapper to deal with
f2c+gcc. The includes the runtime libraries libI77 and libF77.
The sticky bit is what how to handle libI77 and libF77..
g77 has combined these libraries into is libg77.
If g77 were brought into the tree, I think we could delete
src/gnu/usr.bin/cc/f77, src/lib/{f2c, libI77, libF77}, and
src/usr.bin/f2c.
--
Steve
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Boot blocks
In message 19990404232854.a5...@nuxi.com David O'Brien writes: : Were you able to actually boot the bootblocks compiled with EGCS and -Os ? : (I know the optimization gives us the space we need, but I'm not upto : testing new bootblocks at this moment) To be honest, I didn't test them. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
In message xfmail.990405175536.asmo...@wxs.nl Jeroen Ruigrok/Asmodai writes: : Funny thing that it bombs now, whereas I made world fine before. Looks like you didn't get the other of my two changes. It was to src/gnu/usr.bin/cc/cc_drv/Makefile. Make sure that it doesn't have mkstemp.o listed. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make -jn ?
It seems Bob Bishop wrote: World builds OK here now, kernel, bootblocks and all. Good job! Is `make -jn' safe yet? Could turn these test builds round a lot faster :-) Nope... === cc_int make: don't know how to make insn-attrtab.c. Stop *** Error code 2 -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Boot blocks
On 05-Apr-99 Warner Losh wrote: In message 19990404232854.a5...@nuxi.com David O'Brien writes: : Were you able to actually boot the bootblocks compiled with EGCS and -Os : ? : (I know the optimization gives us the space we need, but I'm not upto : testing new bootblocks at this moment) To be honest, I didn't test them. I did, they work, with -O though, due to -Os not working at that point yet... Just tried a make of boot2 after rebooting with the original Makefile which has -Os in it, it compiles. Haven't tested that situation yet, but I don't think it oughtta be that different. --- 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: World Breakage?
On 05-Apr-99 Warner Losh wrote: In message xfmail.990405175536.asmo...@wxs.nl Jeroen Ruigrok/Asmodai writes: : Funny thing that it bombs now, whereas I made world fine before. Looks like you didn't get the other of my two changes. It was to src/gnu/usr.bin/cc/cc_drv/Makefile. Make sure that it doesn't have mkstemp.o listed. Looking at that file now: # $Id: Makefile,v 1.2 1999/04/04 20:29:43 imp Exp $ That seems right... [asmo...@daemon] (13) $ more Makefile | grep mkstemp [asmo...@daemon] (14) $ That's odd... Will nuke /usr/obj again just be sure for 100% on that part, but I think that I oughtta had that problem on my earlier builds as well though... Hmmm... --- 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: World Breakage?
In message xfmail.990405185525.asmo...@wxs.nl Jeroen Ruigrok/Asmodai writes: : Will nuke /usr/obj again just be sure for 100% on that part, but I think : that I oughtta had that problem on my earlier builds as well though... Odd. I completed a make world with my changes... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Atime not set on execution ?
The way programs are executed (by intention) does not run through the code path which would touch the access time. The POSIX.1 specification, IIRC, requires that the atime be updated when the program exits -- this would be very inefficient to do in our VM system. It requires only _marking_ for update upon successful completion. Completion of exec doesn't seem to be specified properly, but it's clear that it is related to replacement of the process image and not to process lifetime. Since POSIX.1 doesn't and shouldn't specify virtual memory, we can consider the process image to be replaced when it is only replaced virtually. My quick and dirty implementation does a VOP_SETATTR(). This does a full update of the atime, but syncing the update to disk is delayed for ufs file systems, so setting atimes for exec is no worse than setting them for read. However, for nfs the updates are synchronous (or at least they were when I last tested this under nfsv2 a couple of years ago), so they are relatively expensive. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Success!
According to Jeroen Ruigrok/Asmodai: make world completed ok. Even rebooted to test the bootblocks (see previous messages) and all is well. Same here except that I don't seem to experiment your problems below. The machine is up and running, WindowMaker is fine and ntpd too. 2x PPro/200, SMP kernel, 64 MB RAM, make world w/o -j. FreeBSD tara.freenix.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Mon Apr 5 16:12:25 CEST 1999 r...@tara:/src/src/sys/compile/nTARA i386 6:49PM up 2:34, 6 users, load averages: 0.00, 0.00, 0.00 remote refid st t when poll reach delay offsetdisp == 127.127.1.0 127.127.1.0 10 - 26 64 377 0.000.0000.93 *127.127.8.0 .DCFa. 0 - 27 64 177 0.00 35.4460.01 Well, sorta, lotsa errors when trying to make a new kernel, fonts are fuqed, Window Maker all of a sudden acts weird with its general menu, ppp gives an ioctl error... My sources are from CTM cvs-cur #5210 made on 1999/04/04 23:14:46. Congrats David ! -- 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
I still get errors on make world
I still get errors, would killing all the source, and re-supping do the trick?? Kenneth Culver To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
C++ with egcs - no go
Just successfully completed a make world and everything appears to be
working correctly (good job, David!), except compiling C++ programs:
/tmp/x cat test.c
#include iostream.h
main()
{
cout Hello world!\n;
}
/tmp/x c++ test.c
/usr/lib/libstdc++.so: undefined reference to `filebuf virtual table'
/usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table'
/tmp/x
I remember someone mentioning this same problem here and it was supposedly
fixed with a later commit. I just cvsupped and got some changes to ppbus
by peter, which as far as I remember were after the latest changes by
David O'Brien, so I guess I do have the latest sources.
Anybody else seeing this after the latest cvsup (as of 15 minutes ago)?
Blaz Zupan, b...@medinet.si, http://home.amis.net/blaz
Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
cpp breakage on egcs -current
I just found that just calling /usr/libexec/cpp -traditional causes it to abort with the following error: /usr/source/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:1882: Internal compiler error in function main This breaks rpcgen thus breaking make buildworld in my box . In addition xdm and xdrb also suffer .. This is on a system on which I ran a succesfull make world last night. The kernel is also built using egcs. This is the only problem I have found so far. The CFLAGS for make world were -O2 -pipe, for the kernel -O -pipe. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CPP broken on egcs current
In article 199904051112.naa22...@trantor.xs4all.nl, Paul van der Zwan pa...@trantor.xs4all.nl wrote: A make buildworld fails on an freshly rebuilt system. The following error is shown: ... /usr/source/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:1882: Int ernal compiler error in function main *** Error code 33 Your installed cpp was built from slightly old sources. Make sure your source tree is up-to-date. Then manually make cleandir; make cleandir; make obj; make depend; make all install in src/gnu/usr.bin/cc. It will be OK after that. 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
aio_read
Terry, In the BUGS section of the 4.0-CURRENT aio_read man page, the following comment is made: The value of iocb-aio_offset is ignored. Is this actually the case, and what would be required to fix it? Does this comment imply that reads always occur at the current file offset from the open file structure? What I would like to do is have a child process read from an inherited file descriptor without affecting the parent process's access to the descriptor (for example, the offset it reads from using a normal read() or readv()). I address this to you because you seem to be listed in the man page as the author of the man page (although it looks like John Dyson has the copyright on the source code?) Thanks, Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
On 05-Apr-99 Warner Losh wrote: In message xfmail.990405185525.asmo...@wxs.nl Jeroen Ruigrok/Asmodai writes: : Will nuke /usr/obj again just be sure for 100% on that part, but I think : that I oughtta had that problem on my earlier builds as well though... Odd. I completed a make world with my changes... Oops, said that wrong: I did _not_ have that problem on my earlier build. Anyways I just rm -rf'd the contents of /usr/obj and trying it again with a fresh cvsup. === rpcsvc rpcgen -C -h -DWANT_NFS3 /work/FreeBSD/src/include/rpcsvc/klm_prot.x -o klm_prot.h /work/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:188 2: Internal compiler error in function main *** Error code 33 Stop. *** Error code 1 *sigh* and it's so easy to find what those error messages mean. Btw, using my previous make world the egcs info files didn't get installed. Seems that the make install target doesn't get called. Need to verify that though. A make make install from the subdir works though as it should. --- 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: aio_read
:Terry, : :In the BUGS section of the 4.0-CURRENT aio_read man page, the following :comment is made: : : The value of iocb-aio_offset is ignored. : :Is this actually the case, and what would be required to fix it? Does :this comment imply that reads always occur at the current file offset from :the open file structure? What I would like to do is have a child process :... : :Thanks, : : Robert N Watson : :rob...@fledge.watson.org http://www.watson.org/~robert/ I believe this either has been fixed or is about to be fixed by Alan. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: C++ with egcs - no go
On 05-Apr-99 Blaz Zupan wrote: /tmp/x c++ test.c /usr/lib/libstdc++.so: undefined reference to `filebuf virtual table' /usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table' /tmp/x Anybody else seeing this after the latest cvsup (as of 15 minutes ago)? Those errors are still present. Watch the cvs messages closely or -current ;) --- 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: I still get errors on make world
On 05-Apr-99 Kenneth Wayne Culver wrote: I still get errors, would killing all the source, and re-supping do the trick?? To ensure a complete clean build try to do this: rm -rf the whole of /usr/obj cvsup one last time then make world or buildworld WITHOUT -j flags. Takes a while, but ensure accurate errors for the remaining errors. That's how I am trying to `help' David ;) --- 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: aio_read
Robert Watson wrote: Terry, In the BUGS section of the 4.0-CURRENT aio_read man page, the following comment is made: The value of iocb-aio_offset is ignored. Is this actually the case, and what would be required to fix it? Does this comment imply that reads always occur at the current file offset from the open file structure? It was true at the time I wrote the manual page, which I verified against the source code for the bugs section. It would be fairly trivial (IMO) to fix this, either by setting the current file offset before doing the read, or, more correctly, using the element offset itself instead (which would allow concurrent aio_read calls on the same fd at staggered offsets). What I would like to do is have a child process read from an inherited file descriptor without affecting the parent process's access to the descriptor (for example, the offset it reads from using a normal read() or readv()). This should be the way it works anyway. The offset is an artifact of the struct file, not the vnode, and a child process inheriting a descriptor does so by making a copy of the parent's open file table into its own open file table -- and thus the child gets its own struct file that points to the vnode, and thus a seperate current offset. An exception to this would be where the parent and child share kernel structures as a result of an rfork() without the RFFDG flag set. I address this to you because you seem to be listed in the man page as the author of the man page (although it looks like John Dyson has the copyright on the source code?) John did the code. I did the man page because I wanted to use it with some test code, but there wasn't a man page. 8-). -- Terry Lambert -- Whistle Communications, Inc. -- te...@whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: aio_read
On Mon, 5 Apr 1999, Terry Lambert wrote: What I would like to do is have a child process read from an inherited file descriptor without affecting the parent process's access to the descriptor (for example, the offset it reads from using a normal read() or readv()). This should be the way it works anyway. The offset is an artifact of the struct file, not the vnode, and a child process inheriting a descriptor does so by making a copy of the parent's open file table into its own open file table -- and thus the child gets its own struct file that points to the vnode, and thus a seperate current offset. This was not my impression; I thought that children had their own descriptor entries on a per-process basis, but that they all pointed to the same open file entry when inherited. I was contemplating adding a modified dup call to allow the duplication of an open file entry to add the behavior you describe, as that is actually the behavior I want. The BSD4.4 book, anyway, fairly clearly states that the behavior is a shared file offset per open file entry, and multiple open file entries pointing to a vnode. (page 205, and better yet, p207 paragraph 3). In some ways this is behavior is nice (multiple processes round-robining on data from a file, for example, or writing to a file, and in particular compatible socket-like or pipe-like behavior), in some ways it is not (desire to have an independent child). An exception to this would be where the parent and child share kernel structures as a result of an rfork() without the RFFDG flag set. I address this to you because you seem to be listed in the man page as the author of the man page (although it looks like John Dyson has the copyright on the source code?) John did the code. I did the man page because I wanted to use it with some test code, but there wasn't a man page. 8-). Sounds good to me; I'm all for documentation. We seem to also need an aio_write page, and an aio_cancel page that documents its brokedness, etc. Maybe I'll stick them together once I finish with this project. Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
On 05-Apr-99 Jeroen Ruigrok/Asmodai wrote: On 05-Apr-99 Warner Losh wrote: In message xfmail.990405185525.asmo...@wxs.nl Jeroen Ruigrok/Asmodai writes: === rpcsvc rpcgen -C -h -DWANT_NFS3 /work/FreeBSD/src/include/rpcsvc/klm_prot.x -o klm_prot.h /work/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:1 882: Internal compiler error in function main *** Error code 33 Stop. *** Error code 1 Tried to remake the cc stuff first as suggested in a previous mail by John Polstra. However this returns me to the mkstemps problem with a source tree which _is_ accurate though... --- 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: aio_read
: :This was not my impression; I thought that children had their own :descriptor entries on a per-process basis, but that they all pointed to :the same open file entry when inherited. I was contemplating adding a They do indeed point to the same file entry. Also, when you dup() a descriptor the two descriptors are pointing to the same file entry. This means that they share the same seek offset... seeking in one descriptor changes the seek position in the other descriptor and even the other descriptor in the other process. UNIX has been broken this way from day 1. It was a major design mistake. The only way to get your own descriptor seek offset is to open() the file again. The aio stuff gets around this by introducing a seek offset in the syscall, but historical use of the file descriptor seek offset broke aio's syscall-based offset. Alan has committed fixes to much of the historical code (in vn_read() and vn_write()) that should mean that aio offsets now work, but I haven't tested it myself. -Matt Matthew Dillon dil...@backplane.com : Robert N Watson : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CPP broken on egcs current
In article 199904051112.naa22...@trantor.xs4all.nl, Paul van der Zwan pa...@trantor.xs4all.nl wrote: A make buildworld fails on an freshly rebuilt system. The following error is shown: ... /usr/source/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:1882: Int ernal compiler error in function main *** Error code 33 Your installed cpp was built from slightly old sources. Make sure your source tree is up-to-date. Then manually make cleandir; make cleandir; make obj; make depend; make all install in src/gnu/usr.bin/cc. It will be OK after that. That seems to fix it.. Thanks. BTW why the double make cleandir ?? a typo ? or is there some magic. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: C++ with egcs - no go
Jeroen Ruigrok/Asmodai wrote:
Those errors are still present.
Wrong:
[(dampurep)~/src]: cat
hello.cc // begin
program
#include iostream
using namespace std;
int main(int argc, char** argv) {
cout Hello World!!!\n endl;
return 0;
}
// end program
[(dampurep)~/src]: c++ -Os -march=pentiumpro -o hello hello.cc
[(dampurep)~/src]: ./hello
Hello World!!!
[(dampurep)~/src]:
PYD
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: CPP broken on egcs current
Paul van der Zwan wrote: BTW why the double make cleandir ?? a typo ? or is there some magic. It helps to ensure that there aren't any old object files in your source tree. The first make cleandir removes the obj directory. The second one removes any generated files from the source directory. There shouldn't be any generated files there, but if there are any it can cause confusing problems. So I usually do the make cleandir twice just to be sure. 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 Breakage?
In message xfmail.990405203100.asmo...@wxs.nl Jeroen Ruigrok/Asmodai writes: : Tried to remake the cc stuff first as suggested in a previous mail by John : Polstra. However this returns me to the mkstemps problem with a source tree : which _is_ accurate though... Can you do an ar: ar tv /usr/obj/mumble/gnu/usr.bin/cc/cc_drv/libcc_drv.a Also make sure that you have version 1.2 of src/gnu/usr.sbin/cc/cc_drv/Makefile. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: C++ with egcs - no go
I made the original post with the below program. I have rebuilt the entire
world using -O2 -pipe -mpentiumpro and all works well. I can safely report
the problem has disappeared. I though I would attempt compiling Qt and see
how that works. I will report back if a problem arrises.
Tom Veldhouse
ve...@visi.com
-Original Message-
From: Pierre Y. Dampure pierre.damp...@k2c.co.uk
To: Jeroen Ruigrok/Asmodai asmo...@wxs.nl
Cc: Blaz Zupan b...@gold.amis.net; freebsd-current@FreeBSD.ORG
freebsd-current@FreeBSD.ORG
Date: Monday, April 05, 1999 1:51 PM
Subject: Re: C++ with egcs - no go
Jeroen Ruigrok/Asmodai wrote:
Those errors are still present.
Wrong:
[(dampurep)~/src]: cat
hello.cc // begin
program
#include iostream
using namespace std;
int main(int argc, char** argv) {
cout Hello World!!!\n endl;
return 0;
}
// end program
[(dampurep)~/src]: c++ -Os -march=pentiumpro -o hello hello.cc
[(dampurep)~/src]: ./hello
Hello World!!!
[(dampurep)~/src]:
PYD
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: C++ with egcs - no go
On 05-Apr-99 Pierre Y. Dampure wrote: Jeroen Ruigrok/Asmodai wrote: Those errors are still present. Wrong: [(dampurep)~/src]: c++ -Os -march=pentiumpro -o hello hello.cc [(dampurep)~/src]: ./hello Hello World!!! [(dampurep)~/src]: OK, they were/are present here =) glad to know they are/might be fixed now. Would gladly test it if my make world would continue, or that I could get rid of this mkstemps. --- 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: World Breakage?
=== rpcsvc rpcgen -C -h -DWANT_NFS3 /work/FreeBSD/src/include/rpcsvc/klm_prot.x -o klm_prot.h /work/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:1 882: Internal compiler error in function main *** Error code 33 This has been fixed. Tried to remake the cc stuff first as suggested in a previous mail by John Polstra. However this returns me to the mkstemps problem with a source tree which _is_ accurate though... Sounds like maybe you should try a different CVSup server. Maybe there is one out there that isn't up to date? -- -- 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: SMP users (important)
: :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. : :This would also suggest shceduler changes that would increasr the :likelyhood of 'related' processes being scheduled together. : :One scheme I remember id the A-list/B-list scheme, where :each scheduling priority has two list that are alternated. :whichever list is being drained is not eligible for receiving new items. :They must go to the other list. When the active list is drained and theya :are switched, the new list is first sorted accoring to affinity :related effects. : :julian This can get real tricky. I think the scheduler will almost do this anyway, just due to the way threads tend to go to sleep and get woken up, so adding a lot of sophistication here may not help. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
=== rpcsvc rpcgen -C -h -DWANT_NFS3 /work/FreeBSD/src/include/rpcsvc/klm_prot.x -o klm_prot.h /work/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:188 2: Internal compiler error in function main *** Error code 33 The fix for this is to CVSup, cd /usr/src/gnu/usr.bin/cc do a build and install from there. -- -- 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?
On 05-Apr-99 Warner Losh wrote:
In message xfmail.990405203100.asmo...@wxs.nl Jeroen Ruigrok/Asmodai
writes:
: Tried to remake the cc stuff first as suggested in a previous mail by
: John Polstra. However this returns me to the mkstemps problem with a
: source tree which _is_ accurate though...
Can you do an ar:
ar tv /usr/obj/mumble/gnu/usr.bin/cc/cc_drv/libcc_drv.a
[r...@daemon] (9) # ar tv libcc_drv.a
rw-r--r-- 0/0920 Apr 5 20:09 1999 version.o
rw-r--r-- 0/0 2035 Apr 5 20:09 1999 pexecute.o
rw-r--r-- 0/0 1889 Apr 5 20:09 1999 prefix.o
rw-r--r-- 0/0 2313 Apr 5 20:09 1999 obstack.o
rw-r--r-- 0/0 2545 Apr 5 20:09 1999 choose-temp.o
Also make sure that you have version 1.2 of
src/gnu/usr.sbin/cc/cc_drv/Makefile.
[r...@daemon] (19) # more Makefile
#
# $Id: Makefile,v 1.2 1999/04/04 20:29:43 imp Exp $
#
.include ../Makefile.inc
.PATH: ../cc_tools ${GCCDIR}
SRCS= multilib.h choose-temp.c obstack.c prefix.c pexecute.c version.c
CFLAGS+=-DPREFIX=\/usr\
CFLAGS+=-DIN_GCC
LIB=cc_drv
NOPROFILE= YES
NOPIC= YES
install:
@true
${OUT_OBJ}.o ${OUT_OBJ}.so: ${OUT_FILE}
.include bsd.lib.mk
Before I tried the make world again with the latest stuff from cvsup I
nuked /usr/obj to obilivion just to be sure...
---
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: I still get errors on make world
On Mon, Apr 05, 1999 at 07:51:00PM +0200, Jeroen Ruigrok/Asmodai wrote: On 05-Apr-99 Kenneth Wayne Culver wrote: I still get errors, would killing all the source, and re-supping do the trick?? To ensure a complete clean build try to do this: rm -rf the whole of /usr/obj cvsup one last time then make world or buildworld WITHOUT -j flags. Takes a while, but ensure accurate errors for the remaining errors. That's how I am trying to `help' David ;) I did additionally the following: rm -rf /usr/include/* cd /usr/src make includes cd /usr/src/gnu/usr.bin/gcc make clean all install -- 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: C++ with egcs - no go
/tmp/x c++ test.c The the list as a whole. For the next week or so, please use the -v flag when reporting compiler problems. -- -- 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: I still get errors on make world
I did additionally the following: rm -rf /usr/include/* cd /usr/src make includes cd /usr/src make -DCLOBBER includes -- -- 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: cpp breakage on egcs -current
I just found that just calling /usr/libexec/cpp -traditional causes it to abort with the following error: /usr/source/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:1882: Internal compiler error in function main This has been fixed. Please CVSup. Then you either need to go back to a pre-EGCS snapshot, or cd /usr/src/gnu/usr.bin/cc make depend make make install. -- -- 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?
On 05-Apr-99 David O'Brien wrote: === rpcsvc rpcgen -C -h -DWANT_NFS3 /work/FreeBSD/src/include/rpcsvc/klm_prot.x -o klm_prot.h /work/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp. c:1882: Internal compiler error in function main *** Error code 33 This has been fixed. I thought so as well. Tried to remake the cc stuff first as suggested in a previous mail by John Polstra. However this returns me to the mkstemps problem with a source tree which _is_ accurate though... Sounds like maybe you should try a different CVSup server. Maybe there is one out there that isn't up to date? cvsup.nl.freebsd.org is one of the better, tracks changes very fast. Anyways, see my mail to Warner in which he asks about an ar and the Makefile revision. Just tried a cvsup again and nothing else came from it. I got all the cvs changes which were mailed to cvs-all, including the Makefile 1.2 from cc_drv. I also nuked /usr/obj, so where else can it get _any_ reference to mkstemps from? --- 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: World Breakage?
Also make sure that you have version 1.2 of src/gnu/usr.sbin/cc/cc_drv/Makefile. You might also need to build libc manually. Looks like maybe you are building parts of the tree manually (to fix the cpp problem), and src/gnu/usr.sbin/cc/cc_drv/Makefile changed between your various compiles. -- -- 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: Make world Broken on my machine
/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/ gcc/gengenrtl.c:22: /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/tm.h:3: linux.h: No such file or directory ^^^ I'm not sure where this came from. I never commited bits that created tm.h that specified linux.h to be included. How are you building cc and friends? -- -- 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: C++
configure:1333: c++ -o conftestconftest.C 15 /usr/lib/libstdc++.so: undefined reference to `filebuf virtual table' /usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table' Some people are getting these errors, but I'm not sure why. It comes from not compiling the compiler and C++ libs with the same ``#define DEFAULT_VTABLE_THUNKS'' value. There may have been a short time window when all the bits were not in sync. -- -- 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: gnu/usr.bin/genclass
genclass has GPPDIR=${BLA}/libg++ in its Makefile breaking the make
world, not sure if you noticed already, didn't see a commit message
about it :-)
Fixed. `genclass' was a little behind libg++ in being disconnected from
the 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: CPP broken on egcs current
Your installed cpp was built from slightly old sources. Make sure your source tree is up-to-date. Then manually make cleandir; make cleandir; make obj; make depend; make all install in src/gnu/usr.bin/cc. It will be OK after that. Thinking about it... some people might need to build libc to get one with mkstemp() in it. Of course that is hard to do if `cpp' is totally broken. If this is the case, people can try adding SRCS += mkstemp.c to src/gnu/usr.bin/cc/cc_drv/Makefile. Once a working ``cpp'' is installed, please remove the above hack though. -- -- 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: make -jn ?
On Mon, 5 Apr 1999, Bob Bishop wrote: World builds OK here now, kernel, bootblocks and all. Good job! Is `make -jn' safe yet? Could turn these test builds round a lot faster :-) I'm running a test build at -j3 now following the reccomended ncpus +1 formula everything looks great so far. if it fails i'll let you know rob To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: aio_read
Matthew Dillon wrote:
:This was not my impression; I thought that children had
:their own descriptor entries on a per-process basis, but
:that they all pointed to the same open file entry when
:inherited. I was contemplating adding a
They do indeed point to the same file entry. Also, when
you dup() a descriptor the two descriptors are pointing
to the same file entry.
This means that they share the same seek offset... seeking
in one descriptor changes the seek position in the other
descriptor and even the other descriptor in the other
process.
UNIX has been broken this way from day 1. It was a major
design mistake.
The only way to get your own descriptor seek offset is to
open() the file again.
After you said this, I found it so hard to believe that I had
to go look.
All I can say is, well I'll be damned; you could knock me over
with a feather, and that doesn't happen often.
I'm sure SVR4 and UnixWare is not like this; I had to write
code explicitly for UnixWare, Solaris, and AIX to get, among
other things, this type of behaviour.
Here's the comment from Solaris:
/*
* One file structure is allocated for each open/creat/pipe call.
* Main use is to hold the read/write pointer associated with
* each open file.
*/
typedef struct file {
It also credits SVr4 11.28 for file.h itself.
I'm pretty sure Ultrix didn't have this bug, either, and it was
4.3 based.
I think it's an artifact of the way the struct file is used
on a list to create the system open file table in BSD 4.4 based
systems (I checked BSDI; it has the bug).
-- Terry Lambert
-- Whistle Communications, Inc.
-- te...@whistle.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: aio_read
On Mon, 5 Apr 1999, Terry Lambert wrote:
After you said this, I found it so hard to believe that I had
to go look.
:-)
All I can say is, well I'll be damned; you could knock me over
with a feather, and that doesn't happen often.
I'm sure SVR4 and UnixWare is not like this; I had to write
code explicitly for UnixWare, Solaris, and AIX to get, among
other things, this type of behaviour.
Here's the comment from Solaris:
/*
* One file structure is allocated for each open/creat/pipe call.
* Main use is to hold the read/write pointer associated with
* each open file.
*/
typedef struct file {
It also credits SVr4 11.28 for file.h itself.
Solaris fork() man page reports:
SunOS 5.6 Last change: 28 Dec 1996 1
System Calls fork(2)
o The child process has its own copy of the parent's
file descriptors and directory streams. Each of the
child's file descriptors shares a common file pointer
with the corresponding file descriptor of the parent.
Sorry :-). Sounds like this is in fact the documented correct behavior on
all the platforms I can get to.
And HPUX:
Each of the child's file descriptors shares a common open file
description with the corresponding file descriptor of the parent.
This implies that changes to the file offset, file access mode, and
file status flags of file descriptors in the parent also affect
those
in the child, and vice-versa.
Hewlett-Packard Company- 1 - HP-UX Release 9.0: August
1992
The linux fork man page doesn't discuss it, but I did note they implement
vfork() as an alias to fork(), suggesting that their fork and exec should
be less efficient than ours?
Robert N Watson
rob...@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C
Carnegie Mellon Universityhttp://www.cmu.edu/
TIS Labs at Network Associates, Inc. http://www.tis.com/
Safeport Network Services http://www.safeport.com/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: C++
configure:1333: c++ -o conftestconftest.C 15 /usr/lib/libstdc++.so: undefined reference to `filebuf virtual table' /usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table' Some people are getting these errors, but I'm not sure why. It comes Never mind, I fixed the problem by doing: cd /usr/src/gnu/lib/libstdc++ make obj make make install Blaz Zupan, b...@medinet.si, http://home.amis.net/blaz Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
On 05-Apr-99 David O'Brien wrote: Also make sure that you have version 1.2 of src/gnu/usr.sbin/cc/cc_drv/Makefile. You might also need to build libc manually. Looks like maybe you are building parts of the tree manually (to fix the cpp problem), and src/gnu/usr.sbin/cc/cc_drv/Makefile changed between your various compiles. [r...@daemon] (2) # pwd /usr/src/lib/libc [r...@daemon] (3) # make rpcgen -C -h -o yp.h /usr/include/rpcsvc/yp.x /work/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:188 2: Internal compiler error in function main *** Error code 33 Uggh, ok. Let's try egcs first again: /usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(choose-tem p.o): In function `make_temp_file': choose-temp.o(.text+0x278): undefined reference to `mkstemps' *** Error code 1 Nice case of chicken egg =) Will try yer suggestion from the reply to John D. Polstra about adding mkstemp.c to the SRCS: just to get egcs working again. Will let ye know how I'd fare... Thanks for yer patience thus far =) --- 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: World Breakage?
Uggh, ok. Let's try egcs first again: /usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(choose-tem p.o): In function `make_temp_file': choose-temp.o(.text+0x278): undefined reference to `mkstemps' *** Error code 1 Nice case of chicken egg =) Will try yer suggestion from the reply to John D. Polstra about adding mkstemp.c to the SRCS: just to get egcs working again. You really need to do ``cd /usr/src/lib/libc'' and make from there. But I think you will have another chickenegg problem. The mkstemp.c in SRCS should over come is one. -- -- 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?
On 05-Apr-99 David O'Brien wrote: Uggh, ok. Let's try egcs first again: /usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(choose- tem p.o): In function `make_temp_file': choose-temp.o(.text+0x278): undefined reference to `mkstemps' *** Error code 1 Nice case of chicken egg =) Will try yer suggestion from the reply to John D. Polstra about adding mkstemp.c to the SRCS: just to get egcs working again. You really need to do ``cd /usr/src/lib/libc'' and make from there. But I think you will have another chickenegg problem. The mkstemp.c in SRCS should over come is one. That's what my error 33 before the egcs was about. So I am _forced_ to use the temporary hack, else I cannot compile either egcs nor libc =( Ah well, at least I gained some more insight into the whole makefile system, will make excellent documention for the PDP. And hurray, it worked! =) David, when we ever meet, mayhaps in one of the coming Dutch FreeBSD cons, remember to buy ye a few drinks =) --- 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: make -jn ?
On Mon, 5 Apr 1999, eagle wrote: On Mon, 5 Apr 1999, Bob Bishop wrote: World builds OK here now, kernel, bootblocks and all. Good job! Is `make -jn' safe yet? Could turn these test builds round a lot faster :-) I'm running a test build at -j3 now following the reccomended ncpus +1 formula everything looks great so far. if it fails i'll let you know rob build completed successfully will experment some more rob To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: aio_read
: design mistake. : The only way to get your own descriptor seek offset is to : open() the file again. : :After you said this, I found it so hard to believe that I had :to go look. : :All I can say is, well I'll be damned; you could knock me over :with a feather, and that doesn't happen often. Same thing happened to me 12 years ago when I first understood this particular brokedness. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make -jn ?
On Mon, 5 Apr 1999, eagle wrote: On Mon, 5 Apr 1999, Bob Bishop wrote: World builds OK here now, kernel, bootblocks and all. Good job! Is `make -jn' safe yet? Could turn these test builds round a lot faster :-) I'm running a test build at -j3 now following the reccomended ncpus +1 formula everything looks great so far. if it fails i'll let you know build completed successfully will experment some more make -j anything greater than 3 fails rob To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: More on rl0 woes
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. Weeelll... I'm a cheap bastard I actually expected it to work - not real fast, but work reliably anyway. I'm trying to convert my home network over to 100Mbs and the box this is going into is not a performance monster. 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? I'll check that tonight. You say 'traffic continues normally.' This is very confusing: SHOW ME AN EXAMPLE OF WHAT YOU MEAN. OK - the ls of the directory remains hung, but I can still ping the box. It's as if NFS reckons it's sent the reply to the READDIR packet, but it never actually made its way out of the card. 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? I ran tcpdump on the server and observed READDIR packets being received, but no response being emitted. 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? I'll try this when I get home. Don't know enough about the contents of NFS packets yet to tell if it's garbled. 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. Orright.. Just give me a little time. Stephen -- The views expressed above are not those of PGS Tensor. We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true.Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs
What will become of f77 which is in src/gnu/usr.bin/cc/f77? This seems to be a good time to decide what will happen with Fortran in the base FreeBSD system. VERY good question. I have no opinion in the matter, but will follow the wishes of others (or Core, or committers, or who ever should make this decision and who ever tells me which way to go). My vote is to include the sources for g77 that go with the egcs suite, but to have a knob in /etc/make.conf (BUILD_G77=yes) to control if they get built or not. Stephen -- The views expressed above are not those of PGS Tensor. We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true.Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Patched RealTek driver -- please test
Okay, today (and over part of the weekend) I ripped the RealTek driver apart and put it back together again, this time in a hopefully working form. The temporary patch version is at the following locations: http://www.freebsd.org/~wpaul/RealTek/test/2.2 source for FreeBSD 2.2.x http://www.freebsd.org/~wpaul/RealTek/test/3.0 source for FreeBSD 3.x/4.x If you've been having problems with RealTek 8139 cards, please try this version and let me know if it makes a differences. All of the main changes are in the transmit code. I also think I know why the transmitter was getting wedged. The sort answer: I'm a twit. The long answer: when ifinit() was changed so that it warned about ifq_maxlen not being set by the driver, I went in and set it to RL_TX_LIST_CNT - 1, which is approximately what I'd done for the other drivers. However the RealTek only has four transmit 'descriptors' which means the ifq_maxlen for the interface was being set to the ridiculously low value of 3. This causes transmissions of large packet sequences to quickly fill up the send queue. (For example, try doing a ping -s 8100 some host and see if it actually works. My bet is that it won't, because this will generate a series of six or seven frames in rapid succession, and after the first 3 or 4, the queue fills up.) In addition to fixing this, I also re-wrote rl_start() and rl_txeof() to hopefully be a little simpler and less brain damaged. I still need to fill in rl_txeoc() correctly, but once I know for sure that I've fixed all the major problems, I can probably do that in an hour or two. I experimented with this driver version using a FreeBSD 2.2.7 server and a FreeBSD 3.0 client (sorry, it's all I had) and I couldn't get NFS to hang. I also bombarded the server with a TCP stream from the client while the NFS test was running and it didn't lock up. -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
EGCS breaks what(1)
Okay, let me be a little clearer ;) What(1) on the kernel no longer works
because previously, the
char sccs[] = { '@', '(', '#', ')' };
char version[] = blahhhfoo;
Was contiguous. However, nowadays, nice EGCS pads 4 bytes (WHY?!?!) between
those. So it appears @(#)\0\0\0\0FreeBSD. in the binary. Of course,
strings are null-terminated... :P I don't know why EGCS does this!
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \__ \ |) |
http://www.freebsd.org _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
loader
I just finished a buildworld, and I'm not sure about the laoder binary. In my obj/usr/src/sys/boot/i386/loader directory, I have 3 files that might be loader: -rw-r--r-- 1 root wheel 135168 Apr 5 19:01 loader -rwxr-xr-x 1 root wheel 121672 Apr 5 19:01 loader.bin* -rwxr-xr-x 1 root wheel 259171 Apr 5 19:01 loader.sym* None of them are the size of my existing (gcc) /boot/loader: -r-xr-xr-x 1 root wheel 126976 Apr 4 17:10 loader* I use CFLAGS of -O -pipe. Can anyone tell me which of the above files gets installed as /boot/loader, and if (from the filesize) I have a good loader or not? This is the last thing worrying me about giong to egcs, and I'm just playing it very cautiously. Thanks. +--- 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
Post-egcs switch console problems
I just cvsupped a few hours ago and rebuild world and the kernel. After the build, I noticed that my CD-ROM drives no longer worked, corrected the kernel config file to use wcd0 instead of acd0, and while I was at it, updated the bootloader config as per the instructions in /usr/src/sys/boot/README. Upon rebooting with the new kernel, I attempted to log in, but random text began appearing on the console, and then the machine ceased to be responsive. I power-cycled, logged in, started x, putzed around, switched back to the console, left for a while, and returned to find the console hosed again. It seemed to be accepting keystrokes, as I could produce audio, but the display would not change. Anyone else having this problem? Any clues as to what might be wrong? -- Brian Buchanan br...@csua.berkeley.edu -- FreeBSD - The Power to Serve! http://www.freebsd.org daemon(n): 1. an attendant power or spirit : GENIUS 2. the cute little mascot of the FreeBSD operating system To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
: Okay, let me be a little clearer ;) What(1) on the kernel no longer works
:because previously, the
:char sccs[] = { '@', '(', '#', ')' };
:char version[] = blahhhfoo;
:Was contiguous. However, nowadays, nice EGCS pads 4 bytes (WHY?!?!) between
:those. So it appears @(#)\0\0\0\0FreeBSD. in the binary. Of course,
:strings are null-terminated... :P I don't know why EGCS does this!
:
: Brian Feldman_ __ ___ ___ ___ ___
: gr...@unixhelp.org_ __ ___ | _ ) __| \
: FreeBSD: The Power to Serve! _ __ | _ \__ \ |) |
: http://www.freebsd.org _ |___/___/___/
'what' is broken. C does not impose any sort of address ordering
restriction on globals or autos that are declared next to each other.
While it is true that programmers regularly make assumptions in regards
to the placement and alignment of fields in structures and the
placement and alignment of arguments to procedures, it does not follow
that programmers can make assumptions in regards to the placement and
alignment of globals.
EGCS is trying to optimize access to the array by aligning it, in order
to reduce cache line burst-from-meory inefficiencies. It happens
to break bad assumptions made in 'what'.
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: libstdc++ is broken
Best described in gnu/10956, libstdc++ has strange undefined reference errors when compiling anything C++. These are the errors: /usr/lib/libstdc++.so: undefined reference to `filebuf virtual table' /usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table' I'm looking into this. But I haven't seen anything oblivious as to the problem. If you do a 2nd `build world' you will get a working C++ system. The problem is part of the the C++ bits get compiled by the old 2.7.2 compiler and some with EGCS. Everything installed in /usr/ that concerns C++ should have been compiled with EGCS. -- -- 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: libstdc++ is broken
/usr/lib/libstdc++.so: undefined reference to `filebuf virtual table' /usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table' I'm looking into this. But I haven't seen anything oblivious as to the problem. If you do a 2nd `build world' you will get a working C++ system. The problem is part of the the C++ bits get compiled by the old 2.7.2 compiler and some with EGCS. Everything installed in /usr/ that concerns C++ should have been compiled with EGCS. agreed. Yesterday I was seeing the same thing, but today I did the first full egcs make world and it works fine now. Cool! -- we are but packets in the internet of life To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
cvsup4.freebsd.org is running behind
It has been brought to my attention that cvsup4.freebsd.org has been lagging freefall significantly in recent days. I checked the logs and its hourly updates from freefall are failing every time. I've written to the maintainers, but haven't reached them yet. If you are trying to follow the fast pace in -current right now, I'd suggest that you avoid cvsup4 until it's fixed. I'll announce that when it happens. Sorry for the inconvenience. Stuff happens. 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: Patched RealTek driver -- please test
Hi Bill, Just tried the new Realtek driver with 4.0, and it works MUCH better. I was seeing weird NFS transmit errors with UDP, and the ping you suggested below did not work with the old driver (it reported an out of buffer space message and didn't transmit any packets). With the new driver, the ping works, and nfsv3 with UDP works flawlessly. Also, ftping into my machine with the Realtek used to yield a max of 66K per second. Now I see closer to 2MB per second. Looks good so far! Thanks! -- Kyle Mestery StorageTek's Storage Networking Group Protect your right to privacy: www.freecrypto.org On Mon, 5 Apr 1999, Bill Paul wrote: Okay, today (and over part of the weekend) I ripped the RealTek driver apart and put it back together again, this time in a hopefully working form. The temporary patch version is at the following locations: http://www.freebsd.org/~wpaul/RealTek/test/2.2source for FreeBSD 2.2.x http://www.freebsd.org/~wpaul/RealTek/test/3.0source for FreeBSD 3.x/4.x If you've been having problems with RealTek 8139 cards, please try this version and let me know if it makes a differences. All of the main changes are in the transmit code. I also think I know why the transmitter was getting wedged. The sort answer: I'm a twit. The long answer: when ifinit() was changed so that it warned about ifq_maxlen not being set by the driver, I went in and set it to RL_TX_LIST_CNT - 1, which is approximately what I'd done for the other drivers. However the RealTek only has four transmit 'descriptors' which means the ifq_maxlen for the interface was being set to the ridiculously low value of 3. This causes transmissions of large packet sequences to quickly fill up the send queue. (For example, try doing a ping -s 8100 some host and see if it actually works. My bet is that it won't, because this will generate a series of six or seven frames in rapid succession, and after the first 3 or 4, the queue fills up.) In addition to fixing this, I also re-wrote rl_start() and rl_txeof() to hopefully be a little simpler and less brain damaged. I still need to fill in rl_txeoc() correctly, but once I know for sure that I've fixed all the major problems, I can probably do that in an hour or two. I experimented with this driver version using a FreeBSD 2.2.7 server and a FreeBSD 3.0 client (sorry, it's all I had) and I couldn't get NFS to hang. I also bombarded the server with a TCP stream from the client while the NFS test was running and it didn't lock up. -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 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
EGCS optimizations
Well, I played around with egcs a bit. I had blown away my original gcc install so I couldn't compare egcs w/ gcc, but I did mess around with egcs's optimization options. My conclusion: Don't bother with -mpentiumpro or -march=pentiumpro. Not only do they not result in better performance, -march=pentiumpro will not run on a K6-2. I dunno about a K6-3. -mcpu does not change the assembly output at all. -march=cpu does change the assembly output, but does not appear to result in any noticeable improvement in performance over not using -m at all. However, -Os does seem to produce slightly smaller binaries compared with -O2 and actually does not appear to cost performance on my PPro-200. before -r--r--r-- 1 root wheel 543096 Apr 5 21:29 /usr/lib/libc.so.3 -r-xr-xr-x 1 root wheel 1517032 Apr 5 20:37 /usr/libexec/cc1 -r-xr-xr-x 1 root wheel 1580456 Apr 5 20:37 /usr/libexec/cc1obj -r-xr-xr-x 1 root wheel 1928112 Apr 5 20:37 /usr/libexec/cc1plus after -r--r--r-- 1 root wheel 538872 Apr 5 21:35 /usr/lib/libc.so.3 -r-xr-xr-x 1 root wheel 1479240 Apr 5 21:47 /usr/libexec/cc1 -r-xr-xr-x 1 root wheel 1538376 Apr 5 21:47 /usr/libexec/cc1obj -r-xr-xr-x 1 root wheel 1876464 Apr 5 21:47 /usr/libexec/cc1plus Compiling up /usr/src/usr.sbin with egcs and libc compiled with: -O2 160 seconds -O2 -march=pentiumpro 162 seconds -Os 161 seconds Which leads me to believe that using -Os might be beneficial. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
Hmm. interesting. My test kernel under GCC was considerably smaller then my test kernel under EGCS, even with -Os. textdata bss dec hex filename 1287575 95512 122972 1506059 16fb0b kernel.gcc -O2 1326304 111628 125708 1563640 17dbf8 kernel.egcs -Os -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
On Mon, 5 Apr 1999, Matthew Dillon wrote: My conclusion: Don't bother with -mpentiumpro or -march=pentiumpro. Not only do they not result in better performance, -march=pentiumpro will not run on a K6-2. I dunno about a K6-3. -mcpu does not change the assembly output at all. -march=cpu does change the assembly output, but does not appear to result in any noticeable improvement in performance over not using -m at all. Totally informally, I replaced libc (compiled with -O2) with one compiled with -mpentiumpro and -O6, and compiling kdebase seemed to run a bit slower (GNU make took longer to traverse directories and egcs took a bit longer to run). Which leads me to believe that using -Os might be beneficial. Have you tried anything beyond -O2? - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Success, again!
David, after my initial round of chickenegg, I got egcs and libc to build with the temporary hack in the Makefile of cc_drv. I then proceeded to do a make world with -Os -pipe, it took about 5 hours with no -j flags, but it succeeded nicely. Kernel built with -pipe -Os -g, lotsa warnings though, but that was expected. Nice job! --- 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: EGCS optimizations
:Totally informally, I replaced libc (compiled with -O2) with one compiled :with -mpentiumpro and -O6, and compiling kdebase seemed to run a bit :slower (GNU make took longer to traverse directories and egcs took a bit :longer to run). : : Which leads me to believe that using -Os might be beneficial. : :Have you tried anything beyond -O2? : :- alex There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. The only other optimization that might be useful is -fomit-frame-pointer, but it makes debugging impossible. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Success, again!
:David, : :after my initial round of chickenegg, I got egcs and libc to build with :the temporary hack in the Makefile of cc_drv. : :I then proceeded to do a make world with -Os -pipe, it took about 5 hours :with no -j flags, but it succeeded nicely. : :Kernel built with -pipe -Os -g, lotsa warnings though, but that was :expected. : :Nice job! : :--- :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 Same here. I didn't have any chicken-an-egg problems, though, but I pulled the tree out of cvs as of early this afternoon after a bunch of fixes went in. I'm running a -Os EGCS kernel on my test box as we speak! -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
On Monday, 5th April 1999, Matthew Dillon wrote:
:char sccs[] = { '@', '(', '#', ')' };
:char version[] = blahhhfoo;
:Was contiguous.
'what' is broken. C does not impose any sort of address ordering
restriction on globals or autos that are declared next to each other.
Well, it's really an abuse of 'what', and not anything wrong with 'what'
ifself. It will continue to work fine doing the job it was designed to do.
The NetBSD folks faced this problem some time ago, and I believe their
solution was to duplicate the version information. So, version[] is the
same as it used to be, and sccs[] is 4 bytes longer than version[] to hold
a complete copy, and the @(#) prefix. This is then completely portable.
Alternately, we could jimmy around with the current hack, and prefix it
with 4 NULs, and see what happened. Sorry, I haven't tested this idea, as
I've not yet made the EGCS jump.
Stephen.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
On Mon, 5 Apr 1999, Matthew Dillon wrote: There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. Really? The pgcc web page (goof.com/pcg) lead me to believe that there were a few more optimizations turned on by -O5 -O6.. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Patched RealTek driver -- please test
Well, I nipped home over my lunch break gave it a try - some progress, of a sort. My NFS problems have gone away (at least under light activity), but it now seems rather sensitive to sending lots of stuff. The symptoms observed are a hard hang of the whole machine, no response to pings or keyboard action. I cant even break into DDB. How I reproduced this is as follows - get the netpipe program off ports, then set up a receiver on the non-realtek machine as follows - NPtcp -s -r Then on the RealTek machine do this - NPtcp -s -t -h non-realtek-hostname -P After about 5 or so lines of throughput stats, it dies in the bum. Stephen -- The views expressed above are not those of PGS Tensor. We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true.Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
:On Mon, 5 Apr 1999, Matthew Dillon wrote: : : There is nothing beyond -O2. Well, there's -O3, which tries to : inline static functions, but that typically isn't beneficial because : it really bloats up the code and subroutine calls on intel cpus are : very fast. : :Really? : :The pgcc web page (goof.com/pcg) lead me to believe that there were a few :more optimizations turned on by -O5 -O6.. : :- alex pgcc != egcs. PGcc is a patchset on top of egcs and I suppose they might have added additinoal -O options, but egcs itself does not go beyond -O3. The PGcc faq indicates that they are slowly folding their stuff into egcs. Hopefully they've fixed the bugs :-). I have not tried compiling a kernel under pgcc but now that FreeBSD has moved to EGCS, it may actually work! -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
