Hi
Just got round to rebuilding a -current kernel on a Libretto 50 with no PCI bus.
make depend in sys/compile/WANDERER dies on:
In file included from ../../dev/mii/dcphy.c:67:
../../dev/pci/pcivar.h:156: pci_if.h: No such file or directory
Do I really need to add PCI...
Duncan
On Tue, Mar 06, 2001 at 05:07:40PM +0900, Makoto MATSUSHITA wrote:
If there is no mean to create *.pl.s, how about using a pipe to pass
an assembler code to as(1) ?
Sounds reasonable: I'll take a look.
Kris
PGP signature
On Fri, Mar 02, 2001 at 08:58:54PM +0300, Andrey A. Chernov wrote:
On Fri, Mar 02, 2001 at 18:05:54 +0200, Ruslan Ermilov wrote:
On Fri, Mar 02, 2001 at 06:00:25PM +0300, Andrey A. Chernov wrote:
On Fri, Mar 02, 2001 at 15:42:27 +0200, Ruslan Ermilov wrote:
I am not checking src/ to see
There's a small typo in /usr/src/sys/sys/sx.h which causes kernel builds to
break unless INVARIANTS is defined.
Patch below against version 1.2 of the file.
Nick
--- /usr/src/sys/sys/sx.h.orig Tue Mar 6 10:57:31 2001
+++ /usr/src/sys/sys/sx.h Tue Mar 6 10:57:38 2001
@@ -78,7 +78,7 @@
Duncan Barclay wrote:
Hi
Just got round to rebuilding a -current kernel on a Libretto 50 with no PCI bus.
make depend in sys/compile/WANDERER dies on:
In file included from ../../dev/mii/dcphy.c:67:
../../dev/pci/pcivar.h:156: pci_if.h: No such file or directory
Do I
On Tue, 6 Mar 2001, Makoto MATSUSHITA wrote:
I've found that current libcrypto/Makefile is not parallel make(1)
unfriendly, since it creates a temporary file to as(1). Followings are
sample session log with "make buildworld -j2":
...
If there is no mean to create *.pl.s, how about using a
Peter Wemm wrote:
Maxim Sobolev wrote:
Duncan Barclay wrote:
Hi
Just got round to rebuilding a -current kernel on a Libretto 50 with no PCI bus.
make depend in sys/compile/WANDERER dies on:
In file included from ../../dev/mii/dcphy.c:67:
Hi,
I reported it about a month ago, but the problem still persists. 5-current
buildworld can't be performed on reasonably recent 4-stable system, hence
source upgrade path from -stable to -current is broken. Please fix.
cc -pipe -O -I/usr/current/src/gnu/usr.bin/perl/libperl
Steve Kargl [EMAIL PROTECTED] wrote:
dump.8 and dump(8) both refer explicitly to nsa0 and nrsa0 whereas
sa0 and nsa0 are the actual device names in -current.
Then this should be fixed.
The non-'r' device names have been standard in -CURRENT for quite
some time. MAKEDEV only creates 'r'-names
In message [EMAIL PROTECTED], Maxim Sobolev writes:
Warner Losh wrote:
In message [EMAIL PROTECTED] Igor Robul writes:
: On Wed, Feb 28, 2001 at 03:00:48PM +0200, Maxim Sobolev wrote:
: Hi Poul,
:
: In revision 1.31 of src/sys/sys/user.h you have added new ki_layout field to
:
Christian Weisgerber wrote:
Steve Kargl [EMAIL PROTECTED] wrote:
dump.8 and dump(8) both refer explicitly to nsa0 and nrsa0 whereas
whoops rsa0
sa0 and nsa0 are the actual device names in
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Maxim Sobolev writes:
Warner Losh wrote:
In message [EMAIL PROTECTED] Igor Robul writes:
: On Wed, Feb 28, 2001 at 03:00:48PM +0200, Maxim Sobolev wrote:
: Hi Poul,
:
: In revision 1.31 of src/sys/sys/user.h you have added
Will Andrews wrote:
[ cc's trimmed, moved to -current ]
On Wed, Feb 28, 2001 at 09:51:08AM -0700, Warner Losh wrote:
So long as it is not forced unconditionally to be static.
I agree.
b) I've not seen the numbers for this. If it is only 1% faster, it
doesn't make sense, even
Any updates? My quick test involving running pkg_version on a system with 92
installed ports, which is very make-intensive operation if ports have origin
recorded, as pkg_version(1) runs `make -V' for each port, shown that
statically-compiled make is about 15% faster than
: Any updates? My quick test involving running pkg_version on a system with 92
: installed ports, which is very make-intensive operation if ports have origin
: recorded, as pkg_version(1) runs `make -V' for each port, shown that
: statically-compiled make is about 15% faster than
Steve Kargl [EMAIL PROTECTED] wrote:
dump.8 and dump(8) both refer explicitly to rsa0 and nrsa0 whereas
sa0 and nsa0 are the actual device names in -current.
Then this should be fixed.
But, what is the correct fix? Add symlink magic to rc.devfs?
Change dump(8)?
Yes, dump(8) and
subscribe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Christian Weisgerber wrote:
Steve Kargl [EMAIL PROTECTED] wrote:
I haven't heard any screaming yet. Besides, this is -CURRENT.
devfs has also abandoned symlinks for 'r' disk devices.
The "r" in tape device names has traditionally meant "r"ewind.
The "r" in disk names (such as rda0) meant
I reported it about a month ago, but the problem still persists. 5-current
buildworld can't be performed on reasonably recent 4-stable system, hence
source upgrade path from -stable to -current is broken. Please fix.
I just did this on 4-STABLE with no problems at all.
M
--
Mark Murray
Christian Weisgerber wrote:
Steve Kargl [EMAIL PROTECTED] wrote:
I haven't heard any screaming yet. Besides, this is -CURRENT.
devfs has also abandoned symlinks for 'r' disk devices.
The "r" in tape device names has traditionally meant "r"ewind.
The "r" in disk names (such as
On Tue, Mar 06, 2001 at 08:37:35PM +0200, Maxim Sobolev wrote:
Any updates? My quick test involving running pkg_version on a system with 92
installed ports, which is very make-intensive operation if ports have origin
recorded, as pkg_version(1) runs `make -V' for each port, shown that
Steve Kargl [EMAIL PROTECTED] wrote:
The "r" in tape device names has traditionally meant "r"ewind.
No.
We've been over this before. If you check the old 4.xBSD releases,
the 'r' clearly means "raw device". Once upon a time there were
tape block devices.
The rewind and non-rewind tape
On Tue, Mar 06, 2001 at 11:01:32PM +, Christian Weisgerber wrote:
The rewind and non-rewind tape device names were changed under
devfs from rsa0 and nrsa0 to sa0 and nsa0, (which IMHO
violates POLA).
They were changed in MAKEDEV long before that. MAKEDEV also provides
'r' names for
Make sure you delete /usr/obj, I just did this too. Sometimes /usr/obj messes
stuff up, also make sure that make.conf and all don't have any conflicting
options set. Usually, I don't use things like -O2 optimizations for new makes.
Make sure that isn't in your CFLAGS, also it would be a help to
I've got a USB programmer for my Flashram for my Garmin GPS.
It doesn't work, and causes blue screen under windows...
Is this the proof for it is broken?
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of
I read something (somewhere) about speeding up buildworlds with a ramdisk
mounted to /usr/obj *IF* you have a lot of RAM but I cant seem to find it
anymore. Any help? What are you guys doing to speed up your worlds? Are
people still passing -j# option to make or is that old school now?
Passing
Do you want to save money and have the fastest most modern internet presence available?
If yes there is only one company for you:
www.northstar-internetsolutions.com
Web Design, Webpage Hosting, System Building, Server Hosting, Virtual hosting, 0800
numbers, Lease Lines, WAP Site
On Tue, Mar 06, 2001 at 06:03:57PM -0800, some SMTP stream spewed forth:
I read something (somewhere) about speeding up buildworlds with a ramdisk
mounted to /usr/obj *IF* you have a lot of RAM but I cant seem to find it
anymore. Any help? What are you guys doing to speed up your worlds? Are
On 07-Mar-01 John Baldwin wrote:
jhb 2001/03/06 18:59:54 PST
Modified files:
sys/kern kern_sig.c
Log:
- Proc locking. Most of signal handling is now MP safe and doesn't require
Giant. The only exception is the CANSIGNAL() macro. Unlocking the proc
On 07-Mar-01 John Baldwin wrote:
On 07-Mar-01 John Baldwin wrote:
jhb 2001/03/06 18:59:54 PST
Modified files:
sys/kern kern_sig.c
Log:
- Proc locking. Most of signal handling is now MP safe and doesn't
require
Giant. The only exception is the
30 matches
Mail list logo
