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
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
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
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
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
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
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
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
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
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
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
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
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.
A make buildworld fails on an freshly rebuilt system.
The following error is shown:
--
Rebuilding /usr/include
--
cd /usr/source/src; SHARED=copies
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
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
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
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
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
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:
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:
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
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
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
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 -
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
: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
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
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
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
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
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
:
: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
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
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;
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.
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
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
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
=== 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
: :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)
=== 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
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...
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
/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
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
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
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
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.
/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
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
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)
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
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.
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,
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
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
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
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
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
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
: 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
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
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
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
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
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
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
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
: 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.
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
/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.
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
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,
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
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
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.
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
: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
: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
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
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
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
: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?
:
100 matches
Mail list logo
