Re: cvs commit: src/share/mk sys.mk
At 20 Feb 2001 07:54:22 GMT,
Kris Kennaway wrote:
> No, MACHINE_CPU is optional. If you don't have it set, you get the
> vanilla C code. So if you don't have it set at all, you'll get C code
> in OpenSSL as it's always been, then the next time you are using the
> updated make(1) and it will set it to i386, which will get you the
> i386 asm code.
>
> Or you can just set MACHINE_CPU immediately and it will build asm code
> on the first pass.
I don't know this is local problem on my environment, but "make
buildworld" with old make(1) failed if I did not set MACHINE_CPU in
/etc/make.conf. So it seems invoked make(1) in
src/secure/lib/libcrypto is old one...
===> secure/lib/libcrypto
"/usr/src/secure/lib/libcrypto/Makefile", line 62: Malformed conditional
(${MACHINE_CPU:Mi686})
"/usr/src/secure/lib/libcrypto/Makefile", line 62: Missing dependency operator
"/usr/src/secure/lib/libcrypto/Makefile", line 67: if-less else
"/usr/src/secure/lib/libcrypto/Makefile", line 67: Need an operator
"/usr/src/secure/lib/libcrypto/Makefile", line 69: if-less endif
"/usr/src/secure/lib/libcrypto/Makefile", line 69: Need an operator
"/usr/src/secure/lib/libcrypto/Makefile", line 321: Malformed conditional
(${MACHINE_CPU:Mi686} || ${MACHINE_CPU:Mi586})
"/usr/src/secure/lib/libcrypto/Makefile", line 321: Missing dependency operator
"/usr/src/secure/lib/libcrypto/Makefile", line 323: Malformed conditional
(${MACHINE_CPU:Mi386})
"/usr/src/secure/lib/libcrypto/Makefile", line 323: Missing dependency operator
"/usr/src/secure/lib/libcrypto/Makefile", line 326: if-less endif
"/usr/src/secure/lib/libcrypto/Makefile", line 326: Need an operator
make: fatal errors encountered -- cannot continue
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/share/mk sys.mk
Kris Kennaway <[EMAIL PROTECTED]> wrote:
>
> On Tue, Feb 20, 2001 at 10:02:57AM +0600, [EMAIL PROTECTED] wrote:
>>
>> Kris Kennaway <[EMAIL PROTECTED]> wrote:
>> >
>> > Modified files:
>> >share/mk sys.mk
>> > Log:
>> > Remove bogus setting of MACHINE_CPU here. There is no need for it.
>>
>> But there MUST be at least one setting for
>> MACHINE_CPU for 'make buildworld' to succeed before new 'make'
>> with this variable is in place.
>
> No, MACHINE_CPU is optional. If you don't have it set, you get the
> vanilla C code. So if you don't have it set at all, you'll get C code
> in OpenSSL as it's always been, then the next time you are using the
> updated make(1) and it will set it to i386, which will get you the
> i386 asm code.
>
> Or you can just set MACHINE_CPU immediately and it will build asm code
> on the first pass.
MACHINE_CPU variable MUST be DEFINED for current
'Makefile' in the 'usr/src/secure/libcrypto' be parsed by the 'make'
without internall definition of that variable. (It stops at the first
"${MACHINE_CPU:Mi686}" construct in the line 62).
N.Dudorov
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/share/mk sys.mk
On Tue, Feb 20, 2001 at 10:02:57AM +0600, [EMAIL PROTECTED] wrote: > > Kris Kennaway <[EMAIL PROTECTED]> wrote: > > > > Modified files: > >share/mk sys.mk > > Log: > > Remove bogus setting of MACHINE_CPU here. There is no need for it. > > But there MUST be at least one setting for > MACHINE_CPU for 'make buildworld' to succeed before new 'make' > with this variable is in place. No, MACHINE_CPU is optional. If you don't have it set, you get the vanilla C code. So if you don't have it set at all, you'll get C code in OpenSSL as it's always been, then the next time you are using the updated make(1) and it will set it to i386, which will get you the i386 asm code. Or you can just set MACHINE_CPU immediately and it will build asm code on the first pass. Kris PGP signature
Re: occasional filesystem corruption
On Tue, Feb 20, 2001 at 09:19:56AM +0200, Vallo Kallaste <[EMAIL PROTECTED]> wrote: > FreeBSD 5.0-CURRENT #0: Mon Feb 12 16:09:09 EET 2001 > [EMAIL PROTECTED]:/usr/src/sys/compile/Myhakas.SMP [snip] Don't be fooled about kernel compile time, the system is built from sources of February 1'st, 11:00:00 GMT and stays so until -current mess will settle down. Sorry. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Do we need a 3. level between stable and cuurent?
On Mon, 19 Feb 2001 17:54:53 +0100, "Leif Neland" wrote: > Do we need a level in between for people who just run current for the > fun of it and for testing. So after the hardcore has tested it in > -current, they commit it to all the monkeys trying to break it, and we > then try it on n^m' combinations of hardware/software. This is a great idea that nobody else has pushed very hard because of resource constraints. :-( Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
occasional filesystem corruption
Hi I have experienced two filesystem corruption cases recently. Both took place in /usr filesystem, the first was file with very big negative size, other one was in mozilla port work tree where six files were lost in deep subdirectory and prevented make clean to clean up. Fsck did usual job and cleaned that up. /usr filesystem resides on SCSI disk and there are no problems with either disk or SCSI controller. Incidentally I haven't had any such problems before and these appeared after installing and using smbfs-1.3.5 port. I've built correct smbfs.ko module, defined SMP by hand in config.mk (it's SMP system). One SMB share stays mounted always, but gets rare use, some two accesses per day or so. I've discovered some kernel messages also, which occasionally appear until the share stays mounted. Any ideas? FreeBSD 5.0-CURRENT #0: Mon Feb 12 16:09:09 EET 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/Myhakas.SMP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (501.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x383fbff real memory = 268435456 (262144K bytes) avail memory = 257400832 (251368K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc03ab000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc03ab09c. Pentium Pro MTRR support enabled VESA: v2.0, 32768k memory, flags:0x1, mode table:0xc00c6954 (c0006954) VESA: Matrox Graphics Inc. npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard IOAPIC #0 intpin 16 -> irq 2 IOAPIC #0 intpin 18 -> irq 5 IOAPIC #0 intpin 19 -> irq 7 IOAPIC #0 intpin 17 -> irq 10 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 (no driver attached) Timecounter "PIIX" frequency 3579545 Hz pci0: at 7.3 (no driver attached) ahc0: port 0xe400-0xe4ff mem 0xfebfc000-0xfebfcfff irq 2 at device 11.0 on pci0 aic7896/97: Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: port 0xe800-0xe8ff mem 0xfebff000-0xfebf irq 2 at device 11.1 on pci0 aic7896/97: Wide Channel B, SCSI Id=7, 32/255 SCBs pcm0: port 0xed80-0xedbf irq 5 at device 12.0 on pci0 fxp0: port 0xee80-0xeebf mem 0xfe80-0xfe8f,0xfebfd000-0xfebfdfff irq 7 at device 13.0 on pci0 fxp0: Ethernet address 00:e0:81:10:50:32 fxp1: port 0xef00-0xef3f mem 0xfea0-0xfeaf,0xfebfe000-0xfebfefff irq 10 at device 15.0 on pci0 fxp1: Ethernet address 00:90:27:54:57:26 ed0: port 0xef80-0xef9f irq 5 at device 18.0 on pci0 ed0: address 00:e0:29:6d:14:19, type NE2000 (16 bit) atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sc0: at flags 0x100 on isa0 sc0: VGA <9 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 BRIDGE 990810, have 4 interfaces -- index 1 type 6 phy 0 addrl 6 addr 00.e0.81.10.50.32 -- index 2 type 6 phy 0 addrl 6 addr 00.90.27.54.57.26 -- index 3 type 6 phy 0 addrl 6 addr 00.e0.29.6d.14.19 ad0: 14649MB [29765/16/63] at ata0-master tagged UDMA33 ad1: 35772MB [72680/16/63] at ata1-master tagged UDMA33 Waiting 5 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a da0 at ahc0 bus 0 target 1 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) da1 at ahc0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) da2 at ahc1 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da2: 3067MB (6281856 512 byte sectors: 255H 63S/T 391C) cd0 at ahc1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medi
Re: cvs commit: src/share/mk sys.mk
Kris Kennaway <[EMAIL PROTECTED]> wrote: > > Modified files: >share/mk sys.mk > Log: > Remove bogus setting of MACHINE_CPU here. There is no need for it. But there MUST be at least one setting for MACHINE_CPU for 'make buildworld' to succeed before new 'make' with this variable is in place. I can 'make installworld' after defining 'MACHINE_CPU= i686' in '/etc/make.conf'. Is it deservs some kind of HEADS UP ? N.Dudorov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proper kernel config procedure ...
> > /usr/src/sys it doesn't always work. I've told Peter, but I think he thinks > > this is a real edge case. > > Well, there's always rm -rf CONFIGDIR So I have concluded. Forward into the past! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proper kernel config procedure ...
On Mon, Feb 19, 2001 at 04:06:23PM -0800, Matthew Jacob wrote: > > > it u sed to be that one would do 'config -r ' to config a kernel, so > > > that it removed the old /sys/compile/ directory ... -r was removed, > > > so is it no longer required to remove the old directory before building > > > the new kernel, or ... ? > > > > Yes. The dependency stuff all just works, you can 'make clean' if you > > really want to do a complete rebuild. > > This doesn't work 100%. In particular if you have a sys that's not part of > /usr/src/sys it doesn't always work. I've told Peter, but I think he thinks > this is a real edge case. Well, there's always rm -rf CONFIGDIR Kris PGP signature
Re: proper kernel config procedure ...
> > it u sed to be that one would do 'config -r ' to config a kernel, so > > that it removed the old /sys/compile/ directory ... -r was removed, > > so is it no longer required to remove the old directory before building > > the new kernel, or ... ? > > Yes. The dependency stuff all just works, you can 'make clean' if you > really want to do a complete rebuild. This doesn't work 100%. In particular if you have a sys that's not part of /usr/src/sys it doesn't always work. I've told Peter, but I think he thinks this is a real edge case. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proper kernel config procedure ...
On Mon, Feb 19, 2001 at 05:45:25PM -0400, The Hermit Hacker wrote: > > it u sed to be that one would do 'config -r ' to config a kernel, so > that it removed the old /sys/compile/ directory ... -r was removed, > so is it no longer required to remove the old directory before building > the new kernel, or ... ? Yes. The dependency stuff all just works, you can 'make clean' if you really want to do a complete rebuild. Kris PGP signature
Re: pooched kernel stuff (linux)
> > Speaking of which -- I've got 2 disks on this box. ad0 is -stable and > da0 is -current. I'm building the -current world right now with > everything mounted under /mnt. When I'm done, is it safe to just > install the world with 'make installworld DESTDIR=/mnt' ? Uh... don't know that one... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: name resolution problems
On Mon, 19 Feb 2001, Wesley Morgan wrote: > Since the big shake-up with -current, I find that mozilla and galeon can > no longer function (both up to date), but lynx has no problems. Mozilla > seems stuck resolving hostnames, yet tcpdump shows no traffic and truss > indicates that it is simply looping around a poll(). The biggest > difference between lynx and mozilla in terms of name resolution is that > mozilla is linked against libc_r... Could there be some problem here? > Is anyone else seeing this? I see that too. I removed ~/.mozilla, and it works well, but only once. At next launch it get stuck in name resolution again, until I remove ~/.mozilla. Weird. Cheers, --fred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
name resolution problems
Since the big shake-up with -current, I find that mozilla and galeon can no longer function (both up to date), but lynx has no problems. Mozilla seems stuck resolving hostnames, yet tcpdump shows no traffic and truss indicates that it is simply looping around a poll(). The biggest difference between lynx and mozilla in terms of name resolution is that mozilla is linked against libc_r... Could there be some problem here? Is anyone else seeing this? -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pooched kernel stuff (linux)
Matthew Jacob writes: > > looks like the usual drill for alpha, w/o lubricant: > > @/alpha/linux/linux_syscall.h:126: warning: `LINUX_SYS_linux_mount' redefined > @/alpha/linux/linux_syscall.h:25: warning: this is the location of the > previous definition > In file included from > /tstsys/modules/linux/../../compat/linux/linux_file.c:53: > machine/../linux/linux_proto.h:346: redefinition of `struct linux_mount_args' > machine/../linux/linux_proto.h:602: warning: redundant redeclaration of > `linux_mount' in same scope > machine/../linux/linux_proto.h:540: warning: previous declaration of > `linux_mount' > /tstsys/modules/linux/../../compat/linux/linux_file.c: In function > `linux_mount': > /tstsys/modules/linux/../../compat/linux/linux_file.c:910: structure has no Sigh. I'll take a whack at fixing it when I get my -current alpha working again. It got pooched last week during the libc mixup. Speaking of which -- I've got 2 disks on this box. ad0 is -stable and da0 is -current. I'm building the -current world right now with everything mounted under /mnt. When I'm done, is it safe to just install the world with 'make installworld DESTDIR=/mnt' ? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
proper kernel config procedure ...
it u sed to be that one would do 'config -r ' to config a kernel, so
that it removed the old /sys/compile/ directory ... -r was removed,
so is it no longer required to remove the old directory before building
the new kernel, or ... ?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
pooched kernel stuff (linux)
looks like the usual drill for alpha, w/o lubricant: @/alpha/linux/linux_syscall.h:126: warning: `LINUX_SYS_linux_mount' redefined @/alpha/linux/linux_syscall.h:25: warning: this is the location of the previous definition In file included from /tstsys/modules/linux/../../compat/linux/linux_file.c:53: machine/../linux/linux_proto.h:346: redefinition of `struct linux_mount_args' machine/../linux/linux_proto.h:602: warning: redundant redeclaration of `linux_mount' in same scope machine/../linux/linux_proto.h:540: warning: previous declaration of `linux_mount' /tstsys/modules/linux/../../compat/linux/linux_file.c: In function `linux_mount': /tstsys/modules/linux/../../compat/linux/linux_file.c:910: structure has no member named `filesystemtype' /tstsys/modules/linux/../../compat/linux/linux_file.c:914: structure has no member named `specialfile' /tstsys/modules/linux/../../compat/linux/linux_file.c:917: structure has no member named `dir' /tstsys/modules/linux/../../compat/linux/linux_file.c:934: structure has no member named `rwflag' /tstsys/modules/linux/../../compat/linux/linux_file.c:945: structure has no member named `rwflag' /tstsys/modules/linux/../../compat/linux/linux_file.c:950: structure has no member named `rwflag' /tstsys/modules/linux/../../compat/linux/linux_file.c:952: structure has no member named `rwflag' /tstsys/modules/linux/../../compat/linux/linux_file.c:954: structure has no member named `rwflag' /tstsys/modules/linux/../../compat/linux/linux_file.c:956: structure has no member named `rwflag' /tstsys/modules/linux/../../compat/linux/linux_file.c:958: structure has no member named `rwflag' *** Error code 1 Stop in /tstsys/modules/linux. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Do we need a 3. level between stable and cuurent?
* Leif Neland <[EMAIL PROTECTED]> [010219 08:54] wrote: > We all know: -current is bleeding edge, expect it to break at random. Don't run it >if you don't know how to fix it. > -stable is for production, it works all the time. > > Do we need a level in between for people who just run current for the fun of it and >for testing. > So after the hardcore has tested it in -current, they commit it to all the monkeys >trying to break it, and we then try it on n^m' combinations of hardware/software. > > I might not be able to fix a problem, but I can report what happens, and if my >-current breaks for a few days, it is no big deal. > > While -current is not for everybody, I believe people like me helps in quality >testing before the stuff hits -stable. > > Perhaps not a level, just a separate file, which contained the date of the last >known version without known major problems. (or "." if no known problems) This is a good idea, however it would take someone dedicated to maintaining this as well as doing regression testing. Those regression tests could easily be ported to -stable making for happier -stable as well as -current users. Are you volunteering? :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: got stuck in the current __sF foo...
On Mon, 19 Feb 2001, Matthew Jacob wrote: > > In message <[EMAIL PROTECTED]> Matthew >Jacob writes: > > : One system got stuck in the current __sF bork... I'm not stuck with: > > > > : Any advice? > > > > Copy a pre Feb 10th libc.so.5 to this box. Alternatively, copy a Feb > > 17 or later one. > > It turns out that no matter what I seem to do, I can't rebuild. Going back from a library with __stdXXX changes to the compat __sF took 2 installworlds for me. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Do we need a 3. level between stable and cuurent?
On Mon, 19 Feb 2001 17:22:43 + Dermot McNally <[EMAIL PROTECTED]> wrote: DM> Nope, -STABLE is for production, -RELEASE is for installing immediately Indeed, in fact there has been at least one release that was *not* tagged for -STABLE (3.0). -- Tell a computer to WIN - you lose! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: got stuck in the current __sF foo...
> In message <[EMAIL PROTECTED]> Matthew Jacob >writes: > : One system got stuck in the current __sF bork... I'm not stuck with: > > : Any advice? > > Copy a pre Feb 10th libc.so.5 to this box. Alternatively, copy a Feb > 17 or later one. It turns out that no matter what I seem to do, I can't rebuild. I think I'll just do the big bomb approach and take another alpha (the Alpha 4100, of all things!) that managed to make it through unscathed and just clone it's disk. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world breakage
Sources updated yesterday: ===> sbin/mountd cc -O -pipe -DNFS -DMFS -DCD9660 -DMSDOSFS -c /usr/src/sbin/mountd/mountd.c /usr/src/sbin/mountd/mountd.c:164: warning: `struct xucred' declared inside parameter list /usr/src/sbin/mountd/mountd.c:164: warning: its scope is only this definition or declaration, which is probably not what you want. /usr/src/sbin/mountd/mountd.c:166: warning: `struct xucred' declared inside parameter list /usr/src/sbin/mountd/mountd.c:187: warning: `struct xucred' declared inside parameter list /usr/src/sbin/mountd/mountd.c:205: variable `def_anon' has initializer but incomplete type /usr/src/sbin/mountd/mountd.c:206: warning: excess elements in struct initializer /usr/src/sbin/mountd/mountd.c:206: warning: (near initialization for `def_anon') /usr/src/sbin/mountd/mountd.c:207: warning: excess elements in struct initializer /usr/src/sbin/mountd/mountd.c:207: warning: (near initialization for `def_anon') /usr/src/sbin/mountd/mountd.c:208: warning: excess elements in struct initializer /usr/src/sbin/mountd/mountd.c:208: warning: (near initialization for `def_anon') /usr/src/sbin/mountd/mountd.c:209: extra brace group at end of initializer /usr/src/sbin/mountd/mountd.c:209: (near initialization for `def_anon') /usr/src/sbin/mountd/mountd.c:209: warning: excess elements in struct initializer /usr/src/sbin/mountd/mountd.c:209: warning: (near initialization for `def_anon') /usr/src/sbin/mountd/mountd.c:211: warning: excess elements in struct initializer /usr/src/sbin/mountd/mountd.c:211: warning: (near initialization for `def_anon') /usr/src/sbin/mountd/mountd.c: In function `get_exportlist': /usr/src/sbin/mountd/mountd.c:736: storage size of `anon' isn't known /usr/src/sbin/mountd/mountd.c: In function `do_opt': /usr/src/sbin/mountd/mountd.c:1337: argument `cr' doesn't match prototype /usr/src/sbin/mountd/mountd.c:166: prototype declaration /usr/src/sbin/mountd/mountd.c:1376: warning: passing arg 2 of `parsecred' from incompatible pointer type /usr/src/sbin/mountd/mountd.c: In function `do_mount': /usr/src/sbin/mountd/mountd.c:1599: argument `anoncrp' doesn't match prototype /usr/src/sbin/mountd/mountd.c:164: prototype declaration /usr/src/sbin/mountd/mountd.c:1618: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c: In function `parsecred': /usr/src/sbin/mountd/mountd.c:1847: argument `cr' doesn't match prototype /usr/src/sbin/mountd/mountd.c:187: prototype declaration /usr/src/sbin/mountd/mountd.c:1858: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1859: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1860: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1878: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1885: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1886: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1888: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1896: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1898: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1903: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1904: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1907: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1907: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1913: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1913: dereferencing pointer to incomplete type /usr/src/sbin/mountd/mountd.c:1916: dereferencing pointer to incomplete type *** Error code 1 Stop in /usr/src/sbin/mountd. *** Error code 1 Jean-Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Do we need a 3. level between stable and cuurent?
I stand corrected... > -Original Message- > From: Dermot McNally [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 19, 2001 9:23 AM > To: [EMAIL PROTECTED] > Cc: freebsd-current@FreeBSD. ORG > Subject: Re: Do we need a 3. level between stable and cuurent? > > > "oldfart@gtonet" wrote: > > > -RELEASE, I thought, is for production. Although, it's true, > -STABLE rarely > > has a stop. > > Nope, -STABLE is for production, -RELEASE is for installing immediately > prior to upgrading it to -STABLE. X.X-STABLE = X.X-RELEASE + fixes + > carefully selected stuff that has been well tested in -CURRENT. > > Dermot > > -- > --- > Dermot McNally, Chief Technical Officer, Directski.com > [EMAIL PROTECTED] http://www.directski.com - ski the web To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Do we need a 3. level between stable and cuurent?
"oldfart@gtonet" wrote: > -RELEASE, I thought, is for production. Although, it's true, -STABLE rarely > has a stop. Nope, -STABLE is for production, -RELEASE is for installing immediately prior to upgrading it to -STABLE. X.X-STABLE = X.X-RELEASE + fixes + carefully selected stuff that has been well tested in -CURRENT. Dermot -- --- Dermot McNally, Chief Technical Officer, Directski.com [EMAIL PROTECTED] http://www.directski.com - ski the web To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Do we need a 3. level between stable and cuurent?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Leif Neland > Sent: Monday, February 19, 2001 8:55 AM > Cc: [EMAIL PROTECTED] > Subject: Do we need a 3. level between stable and cuurent? > > > We all know: -current is bleeding edge, expect it to break at > random. Don't run it if you don't know how to fix it. > -stable is for production, it works all the time. > -RELEASE, I thought, is for production. Although, it's true, -STABLE rarely has a stop. > Do we need a level in between for people who just run current for > the fun of it and for testing. > So after the hardcore has tested it in -current, they commit it > to all the monkeys trying to break it, and we then try it on n^m' > combinations of hardware/software. Actually, I've always thought that's what -STABLE is for? > I might not be able to fix a problem, but I can report what > happens, and if my -current breaks for a few days, it is no big deal. > > While -current is not for everybody, I believe people like me > helps in quality testing before the stuff hits -stable. Actually, I've always thought that's what -STABLE is for? Deja-vu :) > Perhaps not a level, just a separate file, which contained the > date of the last known version without known major problems. (or > "." if no known problems) I think the current HEADS UP given on here is sufficient warning to determine if a make world will build or if there are stops. YMMV OF > > Leif > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Do we need a 3. level between stable and cuurent?
We all know: -current is bleeding edge, expect it to break at random. Don't run it if you don't know how to fix it. -stable is for production, it works all the time. Do we need a level in between for people who just run current for the fun of it and for testing. So after the hardcore has tested it in -current, they commit it to all the monkeys trying to break it, and we then try it on n^m' combinations of hardware/software. I might not be able to fix a problem, but I can report what happens, and if my -current breaks for a few days, it is no big deal. While -current is not for everybody, I believe people like me helps in quality testing before the stuff hits -stable. Perhaps not a level, just a separate file, which contained the date of the last known version without known major problems. (or "." if no known problems) Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3dfx -current compile error
Quoting Harti Brandt <[EMAIL PROTECTED]>: > On Mon, 19 Feb 2001, Edwin Culp wrote: > > Reverting /usr/src/sys/conf/kmod.mk to rev. 1.90 fixes the problem for > the moment. > > harti Thanks, I'll do that right now. ed - EnContacto.Net - CafeMania.Net - InternetSalon.Org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3dfx -current compile error
On Mon, 19 Feb 2001, Edwin Culp wrote:
Reverting /usr/src/sys/conf/kmod.mk to rev. 1.90 fixes the problem for
the moment.
harti
EC>I've got the same problem on my laptop.
EC>
EC>
EC>Quoting Coleman Kane <[EMAIL PROTECTED]>:
EC>
EC>> So, do you need me to do anything or just wait until it gets worked out?
EC>>
EC>> Bruce Evans had the audacity to say:
EC>> >
EC>> > On Mon, 19 Feb 2001, Coleman Kane wrote:
EC>> >
EC>> > > Yeah, this seems to be broken across all modules. I don't know what's
EC>> going on,
EC>> > > but it seems like it never bothers to make the *.o targets. The reason
EC>> mine
EC>> > > pops up with the error is that, alphabetically, it is first on the list.
EC>> If you
EC>> > > remove it from the ports Makefile, the accf_data module brings up the
EC>> error. I
EC>> > > noticed a lot of commit traffic for config, src/share/mk, make and the
EC>> like, so
EC>> > > I figured this to be a 'commit in process' issue. I'm forwarding this to
EC>>
EC>> > > -current mailing list to let them know about the prob.
EC>> >
EC>> > This is because there is now an explicit rule for everything in ${OBJS}
EC>> > (and some other wrong things), so the suffix rule doesn't get used, and
EC>> > objects are "built" by removing .depend.
EC>> >
EC>> > Bruce
EC>> >
EC>>
EC>
EC>
EC>
EC>
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 3dfx -current compile error
I've got the same problem on my laptop.
Quoting Coleman Kane <[EMAIL PROTECTED]>:
> So, do you need me to do anything or just wait until it gets worked out?
>
> Bruce Evans had the audacity to say:
> >
> > On Mon, 19 Feb 2001, Coleman Kane wrote:
> >
> > > Yeah, this seems to be broken across all modules. I don't know what's
> going on,
> > > but it seems like it never bothers to make the *.o targets. The reason
> mine
> > > pops up with the error is that, alphabetically, it is first on the list.
> If you
> > > remove it from the ports Makefile, the accf_data module brings up the
> error. I
> > > noticed a lot of commit traffic for config, src/share/mk, make and the
> like, so
> > > I figured this to be a 'commit in process' issue. I'm forwarding this to
>
> > > -current mailing list to let them know about the prob.
> >
> > This is because there is now an explicit rule for everything in ${OBJS}
> > (and some other wrong things), so the suffix rule doesn't get used, and
> > objects are "built" by removing .depend.
> >
> > Bruce
> >
>
--
EnContacto.Net - InternetSalon.Org - CafeMania.Net
-
EnContacto.Net - CafeMania.Net - InternetSalon.Org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 3dfx -current compile error
So, do you need me to do anything or just wait until it gets worked out?
Bruce Evans had the audacity to say:
>
> On Mon, 19 Feb 2001, Coleman Kane wrote:
>
> > Yeah, this seems to be broken across all modules. I don't know what's going on,
> > but it seems like it never bothers to make the *.o targets. The reason mine
> > pops up with the error is that, alphabetically, it is first on the list. If you
> > remove it from the ports Makefile, the accf_data module brings up the error. I
> > noticed a lot of commit traffic for config, src/share/mk, make and the like, so
> > I figured this to be a 'commit in process' issue. I'm forwarding this to
> > -current mailing list to let them know about the prob.
>
> This is because there is now an explicit rule for everything in ${OBJS}
> (and some other wrong things), so the suffix rule doesn't get used, and
> objects are "built" by removing .depend.
>
> Bruce
>
PGP signature
Re: 3dfx -current compile error
On Mon, 19 Feb 2001, Coleman Kane wrote:
> Yeah, this seems to be broken across all modules. I don't know what's going on,
> but it seems like it never bothers to make the *.o targets. The reason mine
> pops up with the error is that, alphabetically, it is first on the list. If you
> remove it from the ports Makefile, the accf_data module brings up the error. I
> noticed a lot of commit traffic for config, src/share/mk, make and the like, so
> I figured this to be a 'commit in process' issue. I'm forwarding this to
> -current mailing list to let them know about the prob.
This is because there is now an explicit rule for everything in ${OBJS}
(and some other wrong things), so the suffix rule doesn't get used, and
objects are "built" by removing .depend.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Kernel panic while dumping (even in single user mode).
Hi, the kernel panics while dump(8)ing /usr, even in single user mode. This is what DDB says: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x fault code= supervisor read, page not present instruction pointer = 0x8:0x stack pointer = 0x10:0xc86ebcc0 frame pointer = 0x10:0xc86ebd5c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 46 (dump) kernel: type 12 trap, code = 0 Stopped at -0x1: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x fault code= supervisor read, page not present instruction pointer = 0x8:0xc02745ec stack pointer = 0x10:0xc86ebb28 frame pointer = 0x10:0xc86ebb2c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 46 (dump) kernel: type 12 trap, code = 0 Stopped at -0x1: This is my kernel config: # MYTWR: Farid's Machine running FreeBSD-5.0 CURRENT # $Id: MYTWR,v 2.5 2001/02/19 09:43:30 root Exp $ machine i386 cpu I586_CPU ident MYTWR maxusers32 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options DDB #Enable kernel debugger. options MAXMEM="(128*1024)" options MAXDSIZ="(256*1024*1024)" # Allow max. 256 MB of Virtual RAM options DFLDSIZ="(128*1024*1024)" # Can be user-changed up to MAXDSIZ # strings -n 3 /kernel | sed -n 's/^___//p' > MYTWR.from.kernel options INCLUDE_CONFIG_FILE #Include this file in kerneLl options INET#InterNETworking options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enables FFS soft updates support #optionsMFS #Memory Filesystem #optionsMD_ROOT #MD is a potential root device options NFS #Network Filesystem #optionsNFS_ROOT#NFS usable as root device, NFS required # The following are optional (loaded when needed) #optionsMSDOSFS #MSDOS Filesystem #optionsCD9660 #ISO 9660 Filesystem #optionsDEVFS #Device Filesystem #optionsPROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=8000 #Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor #optionsKTRACE #Needed by SvrV4 Emulator (slower) options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev device isa device eisa device pci # Floppy drives device fdc # Floppy Device Controller # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc 1# Keyboard and PS/2 mouse device atkbd # The AT-Keyboard. device vga # Video driver. #optionsVESA# Support for VESA Video Modes # splash screen/screen saver device splash # syscons is the default console driver, resembling an SCO console device sc 1 options MAXCONS=10 # Maximum number of virtual consoles options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)" options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)" options SC_KERNEL_CONS_ATTR="(FG_RED|BG_BLAC
Re: updating from 12/25/1999 -current?
On Mon, Feb 19, 2001 at 01:19:13AM -0800, Herman Tan wrote: > Greetings everyone: > > Will I run into any problems doing a make world from a > 12/25/1999 version of -CURRENT to the latest -current? > I noticed on -RELEASE machines when I went from > 3.3-R to 4.1-R, I had problems because the loaded > kernel doesn't have the modules and I had to use the > Generic kernel in 4.1R and reboot the machine. Any > suggestions? Thanks. It can probably be done, perhaps with a bit of hoop-jumping (see /usr/src/UPDATING), but you may find a binary upgrade to be easier. Kris PGP signature
Re: Make kernel fail in modules after upgrade 4.2 -> 5.0
> During the fixing stages of the libc problem, vinum caused panics fairly > regularly for me (very early on or during fsck). > > I'm now seeing panics in ufs write after medium heavy activity (make world, > no -j) on SMP, no reg dump comes out. Complains about table inconsistent > (don't remember the precise message). Hopefully my hardware is OK; this > machine has been stable for several weeks with upgraded RAM. I've just upgraded from 2001-01-25 to 2001-02-18:0100 CET and everyting seemed to work fine for me... Well, that was not true: The new kernel panics during dump(8), even when running in single user mode. This error is reproducible, though not at exactly the same number of dumped bytes (the dump file is more or less big). Shutting down now frequently leaves unflushed buffers too. I'm just rebuilding with DDB now... Anyone experiencing problems while dumping? Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
please test, vinum + devfs
This gets my vinum config working enough such that I can mount
my pre-devfs configuration, if anyone wants to test/comment please
try this: (you'll need to recompile src/sbin/vinum as well)
Index: vinum.c
===
RCS file: /home/ncvs/src/sys/dev/vinum/vinum.c,v
retrieving revision 1.39
diff -u -r1.39 vinum.c
--- vinum.c 2000/10/23 08:35:36 1.39
+++ vinum.c 2001/02/19 09:54:39
@@ -35,8 +35,8 @@
* otherwise) arising in any way out of the use of this software, even if
* advised of the possibility of such damage.
*
- * $Id: vinum.c,v 1.28 1999/10/12 09:41:20 grog Exp grog $
- * $FreeBSD: src/sys/dev/vinum/vinum.c,v 1.39 2000/10/23 08:35:36 phk Exp $
+ * $Id: vinum.c,v 1.39 2000/10/23 08:35:36 phk Exp $
+ * $FreeBSD: src/sys/dev/vinum/vinum.c,v 1.38 2000/02/29 06:07:39 grog Exp $
*/
#define STATIC static /* nothing while we're
testing XXX */
@@ -53,7 +53,7 @@
#endif
#include
-STATIC struct cdevsw vinum_cdevsw =
+struct cdevsw vinum_cdevsw =
{
vinumopen, vinumclose, physread, physwrite,
vinumioctl, seltrue, nommap, vinumstrategy,
@@ -68,6 +68,9 @@
struct _vinum_conf vinum_conf; /* configuration
information */
+dev_t vinum_daemon_dev;
+dev_t vinum_super_dev;
+
/*
* Called by main() during pseudo-device attachment. All we need
* to do is allocate enough space for devices to be configured later, and
@@ -88,6 +91,10 @@
dqend = NULL;
cdevsw_add(&vinum_cdevsw); /* add the cdevsw entry */
+vinum_daemon_dev = make_dev(&vinum_cdevsw, VINUM_DAEMON_DEV,
+ UID_ROOT, GID_WHEEL, S_IRUSR|S_IWUSR, VINUM_DAEMON_DEV_NAME); /*
+daemon device */
+vinum_super_dev = make_dev(&vinum_cdevsw, VINUM_SUPERDEV,
+ UID_ROOT, GID_WHEEL, S_IRUSR|S_IWUSR, VINUM_SUPERDEV_NAME); /*
+daemon device */
/* allocate space: drives... */
DRIVE = (struct drive *) Malloc(sizeof(struct drive) * INITIAL_DRIVES);
@@ -174,21 +181,33 @@
queue_daemon_request(daemonrq_return, (union daemoninfo) 0); /* stop the
daemon */
tsleep(&vinumclose, PUSER, "vstop", 1); /* and wait for it */
}
-if (SD != NULL)
+if (SD != NULL) {
+ for (i = 0; i < vinum_conf.subdisks_allocated; i++) {
+ struct sd *sd = &vinum_conf.sd[i];
+
+ if (sd->state != sd_unallocated)
+ free_sd(i);
+ }
Free(SD);
+}
if (PLEX != NULL) {
for (i = 0; i < vinum_conf.plexes_allocated; i++) {
struct plex *plex = &vinum_conf.plex[i];
- if (plex->state != plex_unallocated) { /* we have real data there
*/
- if (plex->sdnos)
- Free(plex->sdnos);
- }
+ if (plex->state != plex_unallocated)/* we have real data there
+*/
+ free_plex(i);
}
Free(PLEX);
}
-if (VOL != NULL)
+if (VOL != NULL) {
+ for (i = 0; i < vinum_conf.volumes_allocated; i++) {
+ struct volume *volume = &vinum_conf.volume[i];
+
+ if (volume->state != volume_unallocated)
+ free_volume(i);
+ }
Free(VOL);
+}
bzero(&vinum_conf, sizeof(vinum_conf));
}
@@ -236,6 +255,8 @@
}
}
#endif
+ destroy_dev(vinum_daemon_dev); /* daemon device */
+ destroy_dev(vinum_super_dev);
cdevsw_remove(&vinum_cdevsw);
log(LOG_INFO, "vinum: unloaded\n"); /* tell the world */
return 0;
Index: vinumconfig.c
===
RCS file: /home/ncvs/src/sys/dev/vinum/vinumconfig.c,v
retrieving revision 1.38
diff -u -r1.38 vinumconfig.c
--- vinumconfig.c 2001/02/02 07:14:13 1.38
+++ vinumconfig.c 2001/02/19 10:05:10
@@ -734,6 +734,7 @@
sd->sectors);
if (sd->plexno >= 0)
PLEX[sd->plexno].subdisks--;/* one less subdisk */
+destroy_dev(sd->dev);
bzero(sd, sizeof(struct sd)); /* and clear it out */
sd->state = sd_unallocated;
vinum_conf.subdisks_used--;/* one less sd */
@@ -811,6 +812,7 @@
Free(plex->sdnos);
if (plex->lock)
Free(plex->lock);
+destroy_dev(plex->dev);
bzero(plex, sizeof(struct plex)); /* and clear it out */
plex->state = plex_unallocated;
}
@@ -881,6 +883,7 @@
struct volume *vol;
vol = &VOL[volno];
+destroy_dev(vol->dev);
bzero(vol, sizeof(struct volume)); /* and clear it out */
vol->state = volume_unallocated;
}
@@ -1220,6 +1223,8 @@
if (sd->sectors < 0)
throw_rude_remark(EINVAL, "sd %s has no length spec", sd->name);
+sd->dev = make_dev(&vinum_cdevsw, VINUMRMINOR(VINUM_SD_TYPE, sdno),
updating from 12/25/1999 -current?
Greetings everyone: Will I run into any problems doing a make world from a 12/25/1999 version of -CURRENT to the latest -current? I noticed on -RELEASE machines when I went from 3.3-R to 4.1-R, I had problems because the loaded kernel doesn't have the modules and I had to use the Generic kernel in 4.1R and reboot the machine. Any suggestions? Thanks. HT __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel modules broken (kmod.mk?)
On Mon, 19 Feb 2001, Pierre Y. Dampure wrote:
> "Andrey A. Chernov" wrote:
>
> > Recent -current, 'make' fails ('make depend' works), I got this for
> > _every_ module:
> >
> > ld -r -o 3dfx.kld tdfx_pci.o
> > /usr/libexec/elf/ld: cannot open tdfx_pci.o: No such file or directory
> > *** Error code 1
> >
> > Stop in /usr/src/sys/modules/3dfx.
> >
>
> I think this might be related to Peter Wemm's last commit on
> src/sys/conf/kmod.mk, which seems to remove the .depend file at the start
> of the make. If I revert the change, modules compile OK
After I commented out line 161 of 'kmod.mk' ( @rm -f .depend ) and removed
the linux module from src/sys/modules/Makefile the compile went OK.
Cheers,
--fred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Make kernel fail in modules after upgrade 4.2 -> 5.0
On Sun, 18 Feb 2001, Pete Carah wrote: > This may relate to a commit about noon (PST) today fixing a different > problem. I'm just waiting it out :-) Oh. I'll just wait too. > Welcome to "current" where (especially lately) about half the time things > don't 'make'... (I'm trying to recompile my kernel after recovering > from the libc circus, trying to prevent some new panics) Yeah. I don't know what I smoked yesterday to decide to go 'current' (In fact, it is because mozilla-0.8 doesn't compile/run on 4.2, but reportedly works on 5.0. I bet I just replaced a small set of problems by a larger one...). On the bright side, this will keep me entertained for weeks :-) Thanks for the reply, Cheers, --fred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel modules broken (kmod.mk?)
"Andrey A. Chernov" wrote:
> Recent -current, 'make' fails ('make depend' works), I got this for
> _every_ module:
>
> ld -r -o 3dfx.kld tdfx_pci.o
> /usr/libexec/elf/ld: cannot open tdfx_pci.o: No such file or directory
> *** Error code 1
>
> Stop in /usr/src/sys/modules/3dfx.
>
I think this might be related to Peter Wemm's last commit on
src/sys/conf/kmod.mk, which seems to remove the .depend file at the start
of the make. If I revert the change, modules compile OK
Best Regards,
PYD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
