> 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 shoul
"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 Cor
"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 Cor
In article <199904050513.xaa69...@harmony.village.org>,
Warner Losh 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 M
Matthew Dillon 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
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 m
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 gi
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
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 th
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 ge
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/
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.
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
> > > t
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 MYSubN
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 a
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
To: Wilko Bulte
Cc: obr...@nuxi.com ; curr...@freebsd.org
Date: Mo
I get the following when trying to build the following very simple C++ test:
// begin program
#include
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
> "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 1
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 h
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 Unsubscrib
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/
< 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
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 her
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
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 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
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
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)
>
On 05-Apr-99 Warner Losh wrote:
> In message 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
In message 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.
>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_ f
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
main()
{
cout << "Hello world!\n";
}
/tmp/x> c++ test.c
/usr/lib/libstdc++.so: undefined reference to `filebuf virtual table'
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 additio
In article <199904051112.naa22...@trantor.xs4all.nl>,
Paul van der Zwan 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 ma
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 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 tha
: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 f
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 ar
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 ensu
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
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
On 05-Apr-99 Jeroen Ruigrok/Asmodai wrote:
> On 05-Apr-99 Warner Losh wrote:
>> In message 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/c
:
: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
descrip
> In article <199904051112.naa22...@trantor.xs4all.nl>,
> Paul van der Zwan 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 er
Jeroen Ruigrok/Asmodai wrote:
>
> Those errors are still present.
>
Wrong:
[(dampurep)~/src]: cat
hello.cc // begin
program
#include
using namespace std;
int main(int argc, char** argv) {
cout << "Hello World!!!\n" << endl;
re
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 director
In message 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//gnu/usr.bin/cc/cc_drv/libcc_drv.a
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 Veldhous
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
> > ===> 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
:> :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: (
> ===> 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.bi
On 05-Apr-99 Warner Losh wrote:
> In message 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
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
>
> cvs
> /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 th
> 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
>
> > 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
> configure:1333: c++ -o conftestconftest.C 1>&5
> /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 compil
> 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.or
> 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
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 fa
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. A
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
> > configure:1333: c++ -o conftestconftest.C 1>&5
> > /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 t
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/Ma
> 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 su
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
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 r
:> 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 ha
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 no
>
> 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
>> 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
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
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 t
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
/usr/src/sys/boot/READM
: 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 lo
> > /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++
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, t
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
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 k
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. -m does not change
> the assembly output at all.
David,
after my initial round of chicken<>egg, 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 thoug
: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 bene
:David,
:
:after my initial round of chicken<>egg, 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 warni
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,
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
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 keyb
: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?
:
In the last episode (Apr 05), Alex Zepeda said:
>
> Have you tried anything beyond -O2?
>
There is only -O3, which is just like -O2 except that it tries to
inline all functions.
-Dan Nelson
dnel...@emsphone.com
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscri
>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.
egcs aligns long (>= about 28 bytes) strings to 32-byte boundaries. This
adds up to 27 NULs to sccsid[] depending
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.
When I tested this
1 - 100 of 103 matches
Mail list logo
