* From: David O'Brien obr...@nuxi.com
* So the fix we mentioned might not be needed with the base EGCS. Maybe
* you can just compile all the ports just to see where we stand. I don't
Well, as soon as the first snapshot with the system egcs is released,
I'm planning to grab it and run the
On the offchance that mty problems were chipset related, I swapped the
RealTek with the de0 card in my other machine, a 233MHz k6. It being a
socket 7 mboard presumably has a later PCI bios. Still the same symptoms -
hangs on NFS access. These can be interrupted and other network traffic
Is it normal for atime not to be set on execution of a file ?
I should have thought this would class as an access ?
(I do not have the filesystem mounted -o noatime :-)
This may be questions, but I am running current...
Thankyou.
To Unsubscribe: send mail to majord...@freebsd.org
with
Is it normal for atime not to be set on execution of a file ?
I should have thought this would class as an access ?
It's normal in FreeBSD, although this breaks POSIX.1 conformance.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the
* From: Jordan K. Hubbard j...@zippy.cdrom.com
* As long as that directory is not /var/db/pkg, where I put my package
* information, I agree that it doesn't matter either. :-)
Ok. I'll move it out then.
* I'm not sure that this is a solution so much as a band-aid, however.
Of course.
Some people called the Ricky Willaims Heiman Siloutte shirt, others call it the
Dreaded Football Player shirt. UT and the Downtown Athletic Club have tried to
ban them through the Collegiate Licensing Company, but unsuccessfully.
Thousands of people have got their hands on one of these
See the leading \n's in the Interrupts column (see !!!)
1st is ok using our cc
2nd is using egcs with different compile options.
But error remains the same even with no optimitation
kernel compiled with FreeBSD
In message 199904040913.raa26...@ariadne.tensor.pgs.com,
`shock...@prth.pgs.com' wrote:
On the offchance that mty problems were chipset related, I swapped the
RealTek with the de0 card in my other machine, a 233MHz k6. It being a
socket 7 mboard presumably has a later PCI bios. Still the same
Well, the troubles continue, after much buggering around with an incorrectly
linked cc1 binary, cooked up from I don't know where I ask Is anyone else
seeing this kind of error on make buildworld'ing
In file included from
/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/freebsd.h:28,
According to Alex Zepeda:
Personally, I'd vote for using the new runtime objects, and forcing binary
incompatibility. It's worth it IMO for the exception handling support if
nothing else. However, if you're dead set against it, just back up your
runtime objects, and edit the spec file (like
According to David E . O'Brien:
src/lib/csu/i386-elf will build and install crtbegin.o and crtend.o from
the EGCS sources. Otherwise we have to use the poorer exception
unwinding method.
Is there a runtime overhead of using these files even for C programs ?
--
Ollivier ROBERT -=- FreeBSD:
Just for the stats:
=== gnu/lib/libg++/doc
=== gnu/lib/libgcc
cd: can't cd to /work/FreeBSD/src/gnu/lib/libgcc
*** Error code 2
Stop.
*** Error code 1
Stop.
*** Error code 1
Stop.
*** Error code 1
Stop.
*** Error code 1
Stop.
*** Error code 1
Stop.
Looking in /usr/src/gnu/lib there's no
On the offchance that mty problems were chipset related, I swapped the
RealTek with the de0 card in my other machine, a 233MHz k6. It being a
I have probably same problem here. NFS hangs and other
network traffic is still alive. Though, my situation
differs a little from yours. I have
On Sun, 4 Apr 1999, Andreas Klemm wrote:
See the leading \n's in the Interrupts column (see !!!)
1st is ok using our cc
2nd is using egcs with different compile options.
But error remains the same even with no optimitation
Very strange. It could have something to do with the following,
Bernd Rosauer wrote:
Hi!
I have noticed that egcs-1.1.2 made it into /usr/src/contrib. But 'make
buildworld' does not touch it. What is the intended use of egcs?
Are you running -current? Are you subscribed to the cvs-all
and freebsd-current mailing lists?
sarcasm
The intended use of
Hi,
I have the same problems with Soren's new ATA driver:
fuchur# mount_msdos -o noauto /dev/afd0s4 /zip
mount_msdos: /dev/afd0s4: Invalid argument
With the old driver and slice wfd0s4, this worked with msdos
formatted zip-mediums.
kernel konfig:
--
controller ata0
device
On 4 Apr 1999, Murata Shuuichirou wrote:
In message 199904040913.raa26...@ariadne.tensor.pgs.com,
`shock...@prth.pgs.com' wrote:
On the offchance that mty problems were chipset related, I swapped the
RealTek with the de0 card in my other machine, a 233MHz k6. It being a
socket 7 mboard
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
* Kenneth D. Merry
| Has the worm driver been taken out of current?
| Yes. You have to use cdrecord now for SCSI CD burners.
cdrecord lacks support for a whole lot of CD-burners...
--
Andreas Dobloug : email: andre...@ifi.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with
Hi,
Linuxthreads (http://lt.tar.com/) is supposed to compile cleanly
against 4.0-current after March 22. (quote from the mentioned web
page)
However, I cvsuped -current on March 31. As the Makefile for the
linuxthreads port contains:
.if !exists(${SRC_BASE}/include/pthread/uthread/pthread.h)
In article 19990403222515.a75...@nuxi.com, David O'Brien
obr...@nuxi.com wrote:
Yesterday I changed csu/i386-elf/ to build crtbegin.o and crtend.o
from the EGCS source rather than our home-grown ones. This
afternoon I switch my EGCS development machine back to a purely
stock 4.0 SNAPSHOT and
Cool,
What do you mean by: we are going to have to use sjlj-exceptions type
exception machanism for a while?
Tnks,
Amancio
Yesterday I changed csu/i386-elf/ to build crtbegin.o and crtend.o from
the EGCS source rather than our home-grown ones.
..snip..
I've made the
On Sun, Apr 04, 1999 at 10:39:15AM -0700, Amancio Hasty wrote:
What do you mean by: we are going to have to use sjlj-exceptions type
exception machanism for a while?
-fsjlj-exceptions is on by default.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail
On Sun, 4 Apr 1999, David O'Brien wrote:
Yesterday I changed csu/i386-elf/ to build crtbegin.o and crtend.o from
the EGCS source rather than our home-grown ones.
..snip..
I've made the same fix to lib/csu as I did libgcc, but now am getting
the same weird install problem Poul-Henning
Why are exceptions handling on by default better yet do we know why exception
handling
is not needed by default with gcc-2.8? and has anyone spent time reading
the egcs requirements for exception handling?
Amancio
On Sun, Apr 04, 1999 at 10:39:15AM -0700, Amancio Hasty wrote:
sjlj-exceptions type exception machanism for a while.
Is there any way to tell gcc not to do this by default,
Yes, -fno-sjlj-exceptions, but you will proably get core dumps when you
throw an exception.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail
Hi,
--
Rebuilding tools needed to build libraries
--
[...]
=== cc_int
make: don't know how to make insn-attrtab.c. Stop
*** Error code 2
1 error
*** Error code 2
1 error
***
In message 19990404093848.a76...@nuxi.com David O'Brien writes:
: THE SWITCH HAS BEEN PULLED!
cc -O -pipe -DFREEBSD_ELF
-I/home/imp/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc
-I/home/imp/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/config
-DFREEBSD_NATIVE
Only if you make world with -j x ...
without -j it's working.
make buildworld -j10 /tmp/build.out 21
breaks the same time making the cc_tools :
`gencheck.c' is up to date.
`c-parse.in' is up to date.
`gencheck.c' is up to date.
`c-parse.in' is up to date.
=== cc_int
make: don't know how to
Hello Bob,
Monday, April 05, 1999, 12:03:48 AM, you wrote:
BB --
Rebuilding tools needed to build libraries
BB --
BB [...]
=== cc_int
BB make: don't know how to make
YAY!!
David, consider yourself signed up for a six pack of anything you like
to drink come the next USENIX. First 6 beers are on me (assuming you
don't mind if I pound a 7-up for each beer you drink, that is). :-)
- Jordan
Yesterday I changed csu/i386-elf/ to build crtbegin.o and crtend.o
Andreas Dobloug wrote...
* Kenneth D. Merry
| Has the worm driver been taken out of current?
| Yes. You have to use cdrecord now for SCSI CD burners.
cdrecord lacks support for a whole lot of CD-burners...
Oh really? The old Worm driver only supported HP/Philips and Plasmon
drives.
Of all the gin joints in all the towns in all the world, Alfred Perlstein
had to walk into mine and say:
On 4 Apr 1999, Murata Shuuichirou wrote:
In message 199904040913.raa26...@ariadne.tensor.pgs.com,
`shock...@prth.pgs.com' wrote:
On the offchance that mty problems were chipset
c++ -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe -fno-for-scope
-I/usr/src/gnu/usr.bin/groff/libgroff/../include -DHAVE_UNISTD_H=1
-DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1
-DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1
I should mention that ``make world'' on the alpha should be considered
totally broken until an Alpha developer can tweak the
contrib/egcs/gcc/config/freebsd.h and
contrib/egcs/gcc/config/alpha/freebsd*.h
bits. I would really like to see
contrib/egcs/gcc/config/alpha/freebsd*.h combined into one
Hi,
At 9:38 pm +0200 4/4/99, Martin Blapp wrote:
Only if you make world with -j x ...
without -j it's working.
make buildworld -j10 /tmp/build.out 21
breaks the same time making the cc_tools :
`gencheck.c' is up to date.
`c-parse.in' is up to date.
`gencheck.c' is up to date.
`c-parse.in' is
/usr/obj/home/imp/FreeBSD/src/tmp/usr/lib/libc.a(mktemp.o): In function
`mkstemps':
mktemp.o(.text+0x0): multiple definition of `mkstemps'
/usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(mkstemp.o)(.text+0x0):
first defined here
/usr/libexec/elf/ld: Warning: size of
Only if you make world with -j x ...
without -j it's working.
OH YES! DON'T -j at this time.
I know there are a few dependency problems in the Makefiles at this time.
I wanted to do the minimum number of changes to them to get EGCS'ifed.
(so cvs diff would be useful)
They will be cleaned up
In message 19990404132114.c77...@nuxi.com David O'Brien writes:
: I can't duplicate this problem. Just to be sure... you aren't using
: -DNOCLEAN, -O2 or anything like that, right?
:
: Would it be possible for you to take the March 31st CURRENT snapshot, do
: a fresh CVSup/cvs checkout and try a
The FreeBSD 4.0-CURRENT world appears to be broken. The file that appears
to be causing the problem is pthread_private.h,
included by isatty.c. I can't find anything as to what's causing
the breakage _yet_, but I hope to produce a patch today.
I CVSup'd only minutes ago.
-Chris
To
Try doing a make buildworld. The .if statement in the linuxthreads
Makefile prevents people from using the wrong version of pthread.h. There is
another pthread.h that pertains to using the Posix threads library.
Carlos C. Tapang
http://www.genericwindows.com
-Original Message-
From:
On Sun, 4 Apr 1999, David O'Brien wrote:
I should mention that ``make world'' on the alpha should be considered
totally broken until an Alpha developer can tweak the
contrib/egcs/gcc/config/freebsd.h and
contrib/egcs/gcc/config/alpha/freebsd*.h
bits. I would really like to see
I get the same error. This is more to the error message which I have
included below. I am doing a make buildworld after deleting
everything in /usr/obj. Cvsup from freebsd3.freebsd.org at around 21:00
GMT.
Jim Bloom
bl...@acm.org
c++ -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe
The FreeBSD 4.0-CURRENT world appears to be broken. The file that
appears to be causing the problem is pthread_private.h, included by
isatty.c.
You're the only one reporting this problem. Possibly your /usr/obj isn't
clean?
--
-- David(obr...@nuxi.com -or-
I'm trying to install -CURRENT on a 8MB machine, and it invariably
seems to hang sooner or later in newbuf.
What have we done recently which would screw small-RAM machines ?
It seems to run fine on the 0318 SNAP, so that should provide some
timeframe...
--
Poul-Henning Kamp FreeBSD
CVSup'd at approx 1100 Pacific time:
=== sys/boot/i386/boot2
(cd /usr/src/sys/boot/i386/boot2; m4 boot1.m4 boot1.s) | as -o boot1.o
ld -nostdlib -static -N -e start -Ttext 0x7c00 -o boot1.out boot1.o
objcopy -S -O binary boot1.out boot1
dd if=/dev/zero of=boot2.ldr bs=512 count=1 2/dev/null
cc
At 03:06 PM 4/4/99 +, S. Akmentins-Teilors wrote:
CVSup'd at approx 1100 Pacific time:
=== sys/boot/i386/boot2
(cd /usr/src/sys/boot/i386/boot2; m4 boot1.m4 boot1.s) | as -o boot1.o
ld -nostdlib -static -N -e start -Ttext 0x7c00 -o boot1.out boot1.o
objcopy -S -O binary boot1.out boot1
dd
On Sun, 4 Apr 1999, David O'Brien wrote:
The FreeBSD 4.0-CURRENT world appears to be broken. The file that
appears to be causing the problem is pthread_private.h, included by
isatty.c.
You're the only one reporting this problem. Possibly your /usr/obj isn't
clean?
No,
At 03:06 PM 4/4/99 +, S. Akmentins-Teilors wrote:
CVSup'd at approx 1100 Pacific time:
=== sys/boot/i386/boot2
(cd /usr/src/sys/boot/i386/boot2; m4 boot1.m4 boot1.s) | as -o boot1.o
ld -nostdlib -static -N -e start -Ttext 0x7c00 -o boot1.out boot1.o
objcopy -S -O binary boot1.out
I'm busily making world, but in the meantime, what's the name of the
system compiler going to be, egcs or gcc, or cc? And the C++ one?
+---
Chuck Robey | Interests include any kind of voice or data
what's the name of the system compiler going to be, egcs or gcc, or cc?
And the C++ one?
No change in names. cc/gcc and c++/g++/CC
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of
Just CVSup'd, and the only updates were:
Try again. It can take an hour or so for changes to make it your
favorate CVSup server.
The fix is to remove the string `` FreeBSD/i386 BOOT\n'' from
src/sys/boot/i386/boot2/boot2.c.
The fix is a stopgap messure until the boot2 authors can take a look
Vladimir Kushnir ku...@mail.kar.net wrote:
On Sun, 4 Apr 1999, David O'Brien wrote:
The FreeBSD 4.0-CURRENT world appears to be broken. The file that
appears to be causing the problem is pthread_private.h, included by
isatty.c.
You're the only one reporting this
Hi,
On Sun, Apr 04, 1999 at 04:02:28PM -0700, David O'Brien wrote:
what's the name of the system compiler going to be, egcs or gcc, or cc?
And the C++ one?
No change in names. cc/gcc and c++/g++/CC
Experience says there are a lot of ports which look for egcc and eg++,
so it might be nice
Experience says there are a lot of ports which look for egcc and eg++,
I thought those that do have exlicit CC=egcc and CXX=eg++ in the
Makefiles. We will just remove them.
so it might be nice to add these (and all the other names used for the
port) as hardlinks.
Nope. I still want the
Bruce Evans wrote:
Is it normal for atime not to be set on execution of a file ?
I should have thought this would class as an access ?
It's normal in FreeBSD, although this breaks POSIX.1 conformance.
Bruce
Thanks for the response, there isn't per chance an option to turn this
on is
I've hit this one now too.
Jim Bloom bl...@acm.org wrote:
I get the same error. This is more to the error message which I have
included below. I am doing a make buildworld after deleting
everything in /usr/obj. Cvsup from freebsd3.freebsd.org at around 21:00
GMT.
Jim Bloom
bl...@acm.org
c++
Just succeeded a make world and kernel recompile. A round of applause
for David, please !
David: I'm starting with the PPro optimisations on right now.
PYD
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
I've hit this one now too.
I'm trying to duplicate the problem.
My guess at the fix is to remove the -DHAVE_CC_OSFCN_H=1\ line from
src/gnu/usr.bin/groff/Makefile.cfg. But I can't tell what other problems
this may cause.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To
On Sun, 4 Apr 1999, Daniel Eischen wrote:
Vladimir Kushnir ku...@mail.kar.net wrote:
On Sun, 4 Apr 1999, David O'Brien wrote:
The FreeBSD 4.0-CURRENT world appears to be broken. The file that
appears to be causing the problem is pthread_private.h, included by
isatty.c.
Besides, I can not imagine the base system is going to track egcs. At some
point we will have a newer egcs port and the older system compiler, much as
it was before. At least that is my take on things.
Tom Veldhouse
ve...@visi.com
-Original Message-
From:
Andreas Klemm andr...@klemm.gtn.com wrote:
See the leading \n's in the Interrupts column (see !!!)
1st is ok using our cc
2nd is using egcs with different compile options.
But error remains the same even with no optimitation
...
1 1 22 4072 2533 456 2641 13908 wire243
This seems to fix the problem. I got all the through buildworld and
have installed the code. Man(1) seems to work fine, but I haven't done
a major stress test of groff and the related programs.
Jim Bloom
bl...@acm.org
David O'Brien wrote:
I've hit this one now too.
I'm trying to
In article 19990403193632.a55...@titan.klemm.gtn.com,
Andreas Klemm andr...@klemm.gtn.com wrote:
Got the latest egcs port
# $Id: Makefile,v 1.53 1999/03/30 02:58:02 obrien Exp $
Build X11R6 with the following CFLAGS:
-pipe -mpentiumpro -O2
I'm still running X11 and after ,make
In article 19990404162457.b78...@nuxi.com,
David O'Brien obr...@nuxi.com wrote:
I've hit this one now too.
I'm trying to duplicate the problem.
My guess at the fix is to remove the -DHAVE_CC_OSFCN_H=1\ line from
src/gnu/usr.bin/groff/Makefile.cfg. But I can't tell what other problems
I've been looking into this. The main problem of course is that we're
trying to use an old libg++
Yes.
I think the best fix is to edit src/contrib/libg++/libg++/src/std.h
But src/contrib/libg++ src/gnu/lib/libg++ is about to be ``cvs rm''ed.
IF we wanted to continue to offer libg++ I
David O'Brien wrote:
I think the best fix is to edit src/contrib/libg++/libg++/src/std.h
But src/contrib/libg++ src/gnu/lib/libg++ is about to be ``cvs rm''ed.
That's even better. :-)
IF we wanted to continue to offer libg++ I would need to import libg++
2.8.1.3.
Ick. I'm all for
David O'Brien wrote:
Just CVSup'd, and the only updates were:
Try again. It can take an hour or so for changes to make it your
favorate CVSup server.
The fix is to remove the string `` FreeBSD/i386 BOOT\n'' from
src/sys/boot/i386/boot2/boot2.c.
The fix is a stopgap messure until
The fix is to remove the string `` FreeBSD/i386 BOOT\n'' from
src/sys/boot/i386/boot2/boot2.c.
I take the size increase was caused by the compiler replacement?
AFAIK. BTW, there is now a ``-Os'' size optimzation. It includes all
-O2 optimizations that don't increase the size + some
: 1 1 22 4072 2533 456 2641 13908 wire243 \nclk0 irq
: ^^ !!!
:
:I recognize that from gcc-2.8.1: The cpp behaviour changed and resulted
:in the DEVICE_NAMES macro in vector.h being incorrectly expanded.
Just wanted to let people know that the unmodified boot blocks have
144 bytes free if you compile them -Os and -16 free if you compile
them -O2. -fno-exceptions didn't seem to impact things at all, nor
did -fno-sjlj-exceptions. At least in terms of size. So it looks
like the right fix for the
:On Fri, 2 Apr 1999, Alan Cox wrote:
:
: Now, if you're not using Luoqi's patches to enable multithreaded
: address spaces, you can stop reading here. If you are, you'll
: need to patch i386/i386/swtch.s as follows:
:
:My suggestion is that we apply Luoqi's %fs patch to -current rather than
72 matches
Mail list logo
