Re: compilation failure (in the kernel SCSI code)
On Sun, 12 May 2002, Thierry Herbelot wrote: > the import of GCC3.1 seems to reveal old bugs : > (while cross-compiling a new kernel atfer cross-compiling a new -Current > world under a fresh -Stable) > (the %b flag is not recognized in the printf()s of scsi_low.c) This is just because gcc-3's format recognizer doesn't recognize %b or any of the other nonstandard kernel printf formats yet. Kernels must be compiled with warnings ignored or printf format checking turned off until this is fixed. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf and -CURRENT
On Fri, 10 May 2002 17:46:31 EST, "David W. Chapman Jr." wrote: > > sysctl.conf is also missing. If its not there, it doesn't get > > parsed. You only need make.conf if you wish to put stuff in there. > > same with rc.conf, except everyone puts something in rc.conf > > > N/m on the sysctl.conf I think that one exists now. I think it'd be nice if it didn't. Files that don't contain anything just make for mergemaster annoyance. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [panic] USB related panic
According to Josef Karthauser: > and that you're running it from a module so the debugger doesn't have > access to the symbols. If you get a moment perhaps you could track > down where in the usb code the panic occured. I compile the usb driver > into the kernel to get around the symbol problem. I'll compile a kernel with usb builtin and test it. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
GCC 3.1 generates bounds traps for bogous va_arg() use...
GCC 3.1 whines about these two instances of va_arg() and generates code which calls "int 5" if they are executed. This workaround works for me, but I don't know if this is the correct fix so I won't commit it. In light of this, we may want to change the kernels panic message for these traps to be more informative. Poul-Henning Index: bios.c === RCS file: /home/ncvs/src/sys/i386/i386/bios.c,v retrieving revision 1.52 diff -u -r1.52 bios.c --- bios.c 17 Apr 2002 13:06:35 - 1.52 +++ bios.c 13 May 2002 13:53:27 - @@ -363,7 +363,11 @@ break; case 's': /* 16-bit integer */ +#if 0 i = va_arg(ap, u_short); +#else + i = va_arg(ap, u_int); +#endif stack -= 2; break; @@ -435,7 +439,11 @@ break; case 's': /* 16-bit integer */ +#if 0 i = va_arg(ap, u_short); +#else + i = va_arg(ap, u_int); +#endif *(u_short *)stack = i; stack += 2; break; -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problem with Intel 2011b
Hello
I just got my hands on a Intel 2011b Wireless card, I'm running FreeBSD
current (dated just before gcc 3.1).
Now my problem is that I insert the card and well nothing happens, the
system gets locked, when I remove the card I everything starts working
once again, and it says it can't manage card ("null"), ("null")
Any one got any idea?
mvh /John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sbin/newfs newfs.8 newfs.c
On Friday 10 May 2002 03:35 pm, Giorgos Keramidas wrote: = On 2002-05-02 23:06, Makoto Matsushita wrote: = > = > Mikhail.Teterin> BTW, whatever became of the effort to make a = > Mikhail.Teterin> wrapper called mount_mfs? = > = > See mdmfs(8). It was been there since Jun/2001 (about 10 months = > ago). = = By casully skimming through the text of mdmfs(8) I don't see how it = could be used to mount an MFS filesystem from fstab though :/ It could be -- by making a mount_mfs a symlink to mdmfs. That was the compromise agreed on :-\ However, the entire md things is lacking one important feature of the the old mfs. Mfs was using virtual memory, subject to the general memory management by the OS. md will use either a the real RAM (malloc type) or the swap (swap). This is acceptable for many, but not for all. I, for example, don't have a dedicated swap partition to list in the fstab -- I use the Windows' swap file^ (pagefile.sys) instead*. This is also in the /etc/rc.local, so when the /etc/fstab is processed during boot there is no swap at all and mount_mfs-ing fails... -mi ^This should be offered by sysinstall if the dual-boot configuration is detected at the install time. Also, why can swapon(2), or, at least, swapon(8) automaticly handle swapping onto files? *Since md replaced another system -- vn(4), I'll mention another missing feature -- /etc/vntab. I suspect, one has to be a long entrenched veteran of the FreeBSD project to be allowed to push out features (vnconfig, mount_mfs) without providing _complete_ replacements first. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
On Mon, May 13, 2002 at 07:22:30AM -0700, Dag-Erling Smorgrav wrote: > -- > >>> Rebuilding the temporary build tree > -- > >>> stage 1: bootstrap tools > -- > >>> stage 2: cleaning up the object tree > -- > ===> lib/libtacplus > ===> lib/libutil > ===> lib/libypclnt > ===> lib/compat > ===> lib/libalias > ===> lib/libatm > ===> lib/libbind > ===> lib/libbz2 > ===> lib/libc > /bin/sh:Argument list too long > *** Error code 1 > > Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/lib/libc. > *** Error code 1 > > Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/lib/libc. > *** Error code 1 > > Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/lib. > *** Error code 1 > > Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. > *** Error code 1 > > Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. > *** Error code 1 > > Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. > Doh! My "make release" test for bsd.lib.mk changes wasn't sane -- "make buildworld" is ran with -DNOCLEAN here. I will fix it soon. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38268/pgp0.pgp Description: PGP signature
VLock and 5.0 DP1
When i try to compile Vlock from ports, i get: cc -O -pipe -DUSE_PAM -c vlock.c cc -O -pipe -DUSE_PAM -c signals.c cc -O -pipe -DUSE_PAM -c help.c cc -O -pipe -DUSE_PAM -c terminal.c cc -O -pipe -DUSE_PAM -c input.c input.c:64: security/pam_misc.h: No such file or directory input.c:67: `misc_conv' undeclared here (not in a function) input.c:67: initializer element is not constant input.c:67: (near initialization for `PAM_conversation.conv') Have got any idea how to solve this problem?? Greetings Andrzej Kwiatkowski To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Problem with Intel 2011b
I have used the non-B version with -current and an IBM thinkpad.
What kind of laptop? dmesg output would be nice.
Do any other cards work?
Alan Edmonds
-Original Message-
From: John Angelmo [mailto:[EMAIL PROTECTED]]
Sent: 13 May 2002 15:02
To: current
Cc: freebsd-mobile
Subject: Problem with Intel 2011b
Hello
I just got my hands on a Intel 2011b Wireless card, I'm running FreeBSD
current (dated just before gcc 3.1).
Now my problem is that I insert the card and well nothing happens, the
system gets locked, when I remove the card I everything starts working
once again, and it says it can't manage card ("null"), ("null")
Any one got any idea?
mvh /John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- ===> lib/libtacplus ===> lib/libutil ===> lib/libypclnt ===> lib/compat ===> lib/libalias ===> lib/libatm ===> lib/libbind ===> lib/libbz2 ===> lib/libc /bin/sh:Argument list too long *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/lib/libc. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/lib/libc. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/lib. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: does the order of .a files matter?
On Monday 13 May 2002 02:06 am, Terry Lambert wrote: = > If you think that providing bits on the link line in dependency = > order is a natural way of linking and the "proper" way of doing = > it, how do you explain our improper use of putting object files in = > lexical order in libraries and how do you resolve the contradiction = > that from a build point of view the lexical order is the proper = > way of building and we only get away with that because the = > linker doesn't require object files in archive libraries to be = > in dependency order (or we manually correct the situation by = > duplication)? = I explain the lexical ordering by way of the following commands when = exiting the Makefile in "vi" in command mode: = = !!ls *.c = J[...] = ISRCS= = = 8-). This does not explain anything. Whatever the joke was, I did not get it. The question stands -- why can the object files be given to the linker in arbitrary order, but the the static libraries must be carefully ordered -- possibly even listed multiple times! There is nothing apparent in the .a format, that forces such behaviour. All of our Makefiles list objects in the alphabetical order -- why not sort them once with lorder/tsort and skip the lorder/tsort step from the library build (in bsd.lib.mk)? That would also speed up world-building... = Linking fewer object files into an executable makes the executable = smaller. Smaller executables are better than larger executables from a = putatively "smarter" linker (personally, I measure linker intelligence = as inversely proportional to the resulting executable size, relative = to the idealized executable size). Terry, NONE of this is relevant to the subject. Nobody is criticizing our linker for not putting UNNEEDED objects into the executables. The gaping hole in the linker, that is the subject of this thread, is the linker's inability to find NEEDED objects, which are right in front of its nose. = I had a big gripe, complete with examples involving famous names, = ready to go. But I will replace it with a much smaller response: = = "A craftsman must know his tools". And always seek to improve them. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GCC 3.1 generates bounds traps for bogous va_arg() use...
On Mon, 13 May 2002, Poul-Henning Kamp wrote: > GCC 3.1 whines about these two instances of va_arg() and generates > code which calls "int 5" if they are executed. > > This workaround works for me, but I don't know if this is the > correct fix so I won't commit it. I just committed a correct fix (essentially s/u_short/int/). About the bug: i = va_arg(ap, u_short); has always given undefined behaviour. gcc now detects this at compile time. Whoever changed gcc to do this must feel as strongly as me about this error since they made it a fatal runtime error :-). 4.4BSD-Lite also attempted to detect this error and make it fatal except in the kernel. From the i386 stdarg.h: #ifdef KERNEL #define va_arg(ap, type) \ ((type *)(ap += sizeof(type)))[-1] #else #define va_arg(ap, type) \ ((type *)(ap += sizeof(type) < sizeof(int) ? \ (abort(), 0) : sizeof(type)))[-1] #endif but it is not really possible to do this without using a compiler builtin, and the above code was changed in FreeBSD after a PR or two about it. The most obvious bug in it is that va_arg() is specified to work on structs, and the size of a struct may be smaller than sizeof(int). I first noticed the 4.4BSDLite2 code when every single test prorgam in NIST-PCTS (NIST POSIX Conformance Test Suite) aborted in it. The NIST sources perpetrate va_arg(ap, char) and va_arg(ap, foo_t) (where foo_t _might_ be a sub-integer type) in a central place. Fixing bugs in the test suite is not permitted for attaining conformance, so FreeBSD is again 100% POSIX-non-conformant according to NIST-PCTS :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with Intel 2011b
[EMAIL PROTECTED] wrote:
> I have used the non-B version with -current and an IBM thinkpad.
>
> What kind of laptop? dmesg output would be nice.
> Do any other cards work?
>
> Alan Edmonds
>
> -Original Message-
> From: John Angelmo [mailto:[EMAIL PROTECTED]]
> Sent: 13 May 2002 15:02
> To: current
> Cc: freebsd-mobile
> Subject: Problem with Intel 2011b
>
>
> Hello
>
> I just got my hands on a Intel 2011b Wireless card, I'm running FreeBSD
> current (dated just before gcc 3.1).
> Now my problem is that I insert the card and well nothing happens, the
> system gets locked, when I remove the card I everything starts working
> once again, and it says it can't manage card ("null"), ("null")
>
> Any one got any idea?
>
> mvh /John
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
Well 2011b is a 32bit card (if I'm not mistaking) the 2011 card is the
same as the symbol card but the 2011b card uses 3.3v instead of 5v
So perhaps I need to use:
device pccbb # cardbus (yenta) bridge
device pccard
device cardbus
instead of:
device card# pccard bus
device pcic# PCMCIA bridge
What else can I do?
I use a C Series Lifebook from Fujitsu Siemens
/John
dmesg
Description: application/java-vm
Re: alpha tinderbox failure
Fixed in bsd.lib.mk,v 1.125. On Mon, May 13, 2002 at 07:22:30AM -0700, Dag-Erling Smorgrav wrote: > -- > >>> Rebuilding the temporary build tree > -- > >>> stage 1: bootstrap tools > -- > >>> stage 2: cleaning up the object tree > -- > ===> lib/libtacplus > ===> lib/libutil > ===> lib/libypclnt > ===> lib/compat > ===> lib/libalias > ===> lib/libatm > ===> lib/libbind > ===> lib/libbz2 > ===> lib/libc > /bin/sh:Argument list too long > *** Error code 1 > > Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/lib/libc. > *** Error code 1 > > Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/lib/libc. > *** Error code 1 > > Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/lib. > *** Error code 1 > > Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. > *** Error code 1 > > Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. > *** Error code 1 > > Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38275/pgp0.pgp Description: PGP signature
RE: Problem with Intel 2011b
I haven't tried the NEWCARD stuff (it panics my hp 510 - 16bit bridge chips)
so I can't comment on that.
Did you try booting with the card installed? If you boot verbose
(boot -v) should see it dump the pci id contents. Also check
if /etc/defaults/pccard.conf contains an entry for the card. The
version of -current I have (maybe a few days old) has no entry
explicitly for a 2011B. It might use the same entry as a 2011,
but might have a different id string. I've exceeded my knowledge
at this point, so I'll stop speculating.
Over to you, Warner :-)
-Original Message-
From: John Angelmo [mailto:[EMAIL PROTECTED]]
Sent: 13 May 2002 16:15
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Problem with Intel 2011b
[EMAIL PROTECTED] wrote:
> I have used the non-B version with -current and an IBM thinkpad.
>
> What kind of laptop? dmesg output would be nice.
> Do any other cards work?
>
> Alan Edmonds
>
> -Original Message-
> From: John Angelmo [mailto:[EMAIL PROTECTED]]
> Sent: 13 May 2002 15:02
> To: current
> Cc: freebsd-mobile
> Subject: Problem with Intel 2011b
>
>
> Hello
>
> I just got my hands on a Intel 2011b Wireless card, I'm running FreeBSD
> current (dated just before gcc 3.1).
> Now my problem is that I insert the card and well nothing happens, the
> system gets locked, when I remove the card I everything starts working
> once again, and it says it can't manage card ("null"), ("null")
>
> Any one got any idea?
>
> mvh /John
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
Well 2011b is a 32bit card (if I'm not mistaking) the 2011 card is the
same as the symbol card but the 2011b card uses 3.3v instead of 5v
So perhaps I need to use:
device pccbb # cardbus (yenta) bridge
device pccard
device cardbus
instead of:
device card# pccard bus
device pcic# PCMCIA bridge
What else can I do?
I use a C Series Lifebook from Fujitsu Siemens
/John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Problem with Intel 2011b
> "John" == John Angelmo <[EMAIL PROTECTED]> writes: John> Well 2011b is a 32bit card (if I'm not mistaking) Nope, it's only a 3,3V 16 bits card. If you're using -stable, the following is needed : > cat /etc/pccard.conf # Intel PRO/Wireless 2011B LAN PC Card card "Intel" "PRO/Wireless LAN PC Card" config auto "wi" ? 0x1 insert /etc/pccard_ether $device start remove /etc/pccard_ether $device stop The 2011 nor the 2011b work on my box (Thinkpad 390) whilst the 2011 works on a Satellite Pro 430 CDS (no 3,3 V slot for the 2011b). dmesg on the Satellite : Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-STABLE #0: Tue Apr 30 12:29:58 CEST 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/TSP430CDS Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (120.00-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf real memory = 50528256 (49344K bytes) avail memory = 46747648 (45652K bytes) pnpbios: Bad PnP BIOS data checksum Preloaded elf kernel "kernel" at 0xc0278000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc027809c. Intel Pentium detected, installing workaround for F00F bug apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface isa0: on motherboard orm0: at iomem 0xe4000-0xe on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 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 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> pcic0: at port 0x3e0 iomem 0xd on isa0 pcic0: Polling mode pccard0: on pcic0 pccard1: on pcic0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold lpt0: on ppbus0 lpt0: Interrupt-driven port BRIDGE 020214 loaded ad0: 1295MB [2633/16/63] at ata0-master BIOSPIO acd0: CDROM at ata1-master BIOSPIO Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 wi0 at port 0x280-0x2c7 iomem 0xd4000-0xd43ff irq 3 flags 0x1 slot 0 on pccard0 wi0: 802.11 address: 00:03:47:b4:8a:c1 wi0: using RF:PRISM2 MAC:HFA3841 wi0: Symbol Firmware: Primary 2.01.02, Station 2.20.02 ep0: <3Com 3C556> at port 0x240-0x25f irq 5 flags 0x1 slot 1 on pccard1 ep0: Ethernet address 00:00:86:53:74:3e dmesg on the Thinkpad : Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.6-PRERELEASE #0: Fri May 3 13:51:21 CEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TP390PNP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (266.62-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 268369920 (262080K bytes) avail memory = 257867776 (251824K bytes) Preloaded elf kernel "kernel" at 0xc033e000. Preloaded elf module "procfs.ko" at 0xc033e09c. Preloaded elf module "if_an.ko" at 0xc033e13c. Preloaded elf module "snd_mss.ko" at 0xc033e1dc. Preloaded elf module "snd_pcm.ko" at 0xc033e27c. Preloaded elf module "ums.ko" at 0xc033e31c. Preloaded elf module "ipl.ko" at 0xc033e3b8. Preloaded elf module "if_wi.ko" at 0xc033e454. VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc027ee42 (122) VESA: MagicGraph 256 AV 48K Pentium Pro MTRR support enabled Using $PIR table, 4 entries at 0xc00fdf80 apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: port 0xfcd0-0xfcdf at device 2.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xfce0-0xfcff irq 11 at device 2.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Microsoft Microsoft IntelliMouse® Optical, rev 1.10/1.21, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. intpm0: port 0x1040-0x104f irq 9 at device 2.3 on pci0 intpm0: I/O mapped 1040 intpm0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped 1000 pcic0: mem 0x1000-0x1fff irq 11 at device 3.0 on pci0 pcic0: TI12XX PCI Config Reg: [speaker enable][pwr save][CSC serial isa irq] pccard0: on pcic0 pcic1: mem 0x1010-0x10100fff irq 11 at device 3.1 on pci0 pcic1: TI1
Re: Special fx with disklabel(8)?
> From: Wilko Bulte <[EMAIL PROTECTED]> > > [misinformation from Terry and lots of flamage snipped] > > Gentlemen.. does this discussion on a public list serve any useful purpose? Of course it does ... it's training newcomers to the list and people who peruse the list archives in the future to ignore Terry Lambert. -- Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Argument list too long in BUILDWORLD
Hi, I've got error : /bin/sh:Argument list too long, while making buildworld, I haven't found any solution in archives, can you help me? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Argument list too long in BUILDWORLD
wizard> I've got error : wizard> /bin/sh:Argument list too long, wizard> while making buildworld, IIRC, it is already fixed; re-cvsup again. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Argument list too long in BUILDWORLD
If my memory serves me right doesn't NO_WERROR=yes in your /etc/make.conf file do that? ed Quoting Martin Kacerovsky <[EMAIL PROTECTED]>: | Hi, | I've got error : | /bin/sh:Argument list too long, | while making buildworld, | I haven't found any solution in archives, can you help me? | Martin | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | --- The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn and relearn. --Alvin Toffler - http://insourcery.com - Mergence of Business and Technology a "Griffin Plaza Partners, LLC" Company To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Argument list too long in BUILDWORLD
Nope, sorry. My memory didn't server me right. sorry, ed Quoting Edwin Culp <[EMAIL PROTECTED]>: | If my memory serves me right doesn't | | NO_WERROR=yes | | in your /etc/make.conf file do that? | | ed | | Quoting Martin Kacerovsky <[EMAIL PROTECTED]>: | | | Hi, | | I've got error : | | /bin/sh:Argument list too long, | | while making buildworld, | | I haven't found any solution in archives, can you help me? | | Martin | | | | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | | with "unsubscribe freebsd-current" in the body of the message | | | | | --- |The illiterate of the 21st century will not be | those who cannot read and write, |but those who cannot learn, unlearn and relearn. | --Alvin Toffler | | - | http://insourcery.com - Mergence of Business and Technology | a "Griffin Plaza Partners, LLC" Company | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | --- The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn and relearn. --Alvin Toffler - http://insourcery.com - Mergence of Business and Technology a "Griffin Plaza Partners, LLC" Company To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: does the order of .a files matter?
Mikhail Teterin wrote: > = I explain the lexical ordering by way of the following commands when > = exiting the Makefile in "vi" in command mode: > = > = !!ls *.c > = J[...] > = ISRCS= > = > = 8-). > > This does not explain anything. Whatever the joke was, I did not get it. These are the commands you give the editor to take the output of "ls *.c", and put all the files on a single line: SRCS=aardvark.c bear.c cat.c dog.c elephant.c ... In other words, the lexical ordering comes from the fact that the output of the "ls" command is sorted alphabetically. > The question stands -- why can the object files be given to the linker > in arbitrary order, Because .o files are object files which it is mandatory to include in the final executable. > but the the static libraries must be carefully ordered -- possibly > even listed multiple times! Because .a files are archives containing lists of object files which it is *optional* to include in the final executable. > There is nothing > apparent in the .a format, that forces such behaviour. Uh... .a files are archives containing lists of object files which it is *optional* to include in the final executable. > All of our Makefiles list objects in the alphabetical order -- why > not sort them once with lorder/tsort and skip the lorder/tsort step > from the library build (in bsd.lib.mk)? That would also speed up > world-building... Because programmers are intrinsically lazy, and write Makefile's last? Also, the speedup is really questionable. The dependency graph is going to be created as if the symbol satisfaction order were random anyway. And, in fact, unless you put one function per object file, you really can't guarantee that tsort will minimize the sorting necessary. You are assuming -- perhaps incorectly -- that the functions were broken up between source files in tsort order. > = Linking fewer object files into an executable makes the executable > = smaller. Smaller executables are better than larger executables from a > = putatively "smarter" linker (personally, I measure linker intelligence > = as inversely proportional to the resulting executable size, relative > = to the idealized executable size). > > Terry, NONE of this is relevant to the subject. Nobody is criticizing > our linker for not putting UNNEEDED objects into the executables. The > gaping hole in the linker, that is the subject of this thread, is the > linker's inability to find NEEDED objects, which are right in front of > its nose. We apparently differ on our definitions of "right in front of its nose". Also... it's not "our linker", it is "FSF's linker". See also the "info ld"; if you wanted an implicit "--start-group" at the start of all object lists, and an implicit "--end-group" at the end, then you could hack it to support it. But, I would not want it in my local FreeBSD; from the documentation: Using this option has a significant performance cost. It is best to use it only when there are unavoidable circular references between two or more archives. > = I had a big gripe, complete with examples involving famous names, > = ready to go. But I will replace it with a much smaller response: > = > = "A craftsman must know his tools". > > And always seek to improve them. Or invent new ones, leaving the old ones intact. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with Intel 2011b
In message <[EMAIL PROTECTED]> Eric Masson writes: : John> Well 2011b is a 32bit card (if I'm not mistaking) : : Nope, it's only a 3,3V 16 bits card. H, I've found that the Intel PRO/Wireless are 5.0V devices. Maybe this is a different card than what I'm used to dealing with. : If you're using -stable, the following is needed : : > cat /etc/pccard.conf : # Intel PRO/Wireless 2011B LAN PC Card : card "Intel" "PRO/Wireless LAN PC Card" : config auto "wi" ? 0x1 : insert /etc/pccard_ether $device start : remove /etc/pccard_ether $device stop : : The 2011 nor the 2011b work on my box (Thinkpad 390) whilst the 2011 : works on a Satellite Pro 430 CDS (no 3,3 V slot for the 2011b). Looks like i82365A/B do not have 3.3V support at all. I can't find the data sheets for them, and the people that do have access tell me that this is correct. I'm not sure why your thinkpad isn't working. Maybe it is an issue related to the COR reset proceedure that we're not doing anymore. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with Intel 2011b
In message: <[EMAIL PROTECTED]>
John Angelmo <[EMAIL PROTECTED]> writes:
: Hello
:
: I just got my hands on a Intel 2011b Wireless card, I'm running FreeBSD
: current (dated just before gcc 3.1).
: Now my problem is that I insert the card and well nothing happens, the
: system gets locked, when I remove the card I everything starts working
: once again, and it says it can't manage card ("null"), ("null")
:
: Any one got any idea?
Nope.
However, if you boot -v, and send me the dmesg maybe I can help.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Special fx with disklabel(8)?
Ian wrote: > > From: Wilko Bulte <[EMAIL PROTECTED]> > > [misinformation from Terry and lots of flamage snipped] > > > > Gentlemen.. does this discussion on a public list serve any useful purpose? > > Of course it does ... it's training newcomers to the list and people who > peruse the list archives in the future to ignore Terry Lambert. Hi, Ian. Read the original poster's followup. He's running a BIOS from 1998. I was right. And Poul added nothing to solving the problem; he was only taking an opportunity to attack someone. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
makefiles broken with make -j?
Hi, It looks like the makefiles are a bit broken if make -j13 is used. What I see here is that osreldate.h in obj/usr/src/i386/usr/include/ looks like this: ... #ifdef _KERNEL #ifdef _KERNEL #error "/usr/include/osreldate.h cannot be used in the kernel, use sys/param.h" #error "/usr/include/osreldate.h cannot be used in the kernel, use sys/param.h" #else #else #undef __FreeBSD_version #undef __FreeBSD_version #define __FreeBSD_version 500035 #define __FreeBSD_version 500035 #endif #endif When looking at the output of "make -j13 world", it looks like some parts are being run more than once: -- >>> stage 4: populating /usr/obj/usr/src/i386/usr/include -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORM AT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/li bdata/perl/5.6.1 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH= /usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i38 6/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/inst all.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/ obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 S HARED=symlinks includes incsinstall ===> share/info ===> share/info ===> include ===> include Setting up symlinks to kernel source tree... John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
installworld problem with /usr/src/usr.bin/tip/tip
I get the following everytime I make installworld on -current ln: /usr/bin/cu: Operation not permitted *** Error code 1 To fix it I have to modify /usr/src/usr.bin/tip/tip/Makefile and remove the LINKS to cu and then all works well. Is anyone else having this problem? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
GCC-3.1 Optimization -Os broken
Hi, after a "make world" I noticed that my dialout was broken (NAT for UDP packets seems to work but not for TCP). After a few tests I finally found the bug: -Os compilation seems broken with gcc-3.1. I normally compile complete world with -Os (instead of -O) (via CFLAGS=-Os in /etc/make.conf). I narrowed the ppp dialout down to libalias: - recompile libalias with -Os => NAT broken - recompile libalias with -O => NAT works again. I know any other optimization than -O isn't supported but this bug (either in libalias or in gcc) should be investigated. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The future of perl on FreeBSD
> "Garance" == Garance A Drosihn <[EMAIL PROTECTED]> writes: Garance> I agree. That's why a redirector makes more sense, because Garance> the redirector can be part of the base-system, and the port Garance> can be installed in /usr/local. There is one problem with the /usr/bin/perl redirector: it can cause autoconfiguration scripts to mistakenly think perl is installed on the system (they find the /usr/bin/perl wrapper) when it isn't (there is no perl-from-ports backing the redirector). --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The future of perl on FreeBSD
On Mon May 13, 2002 at 02:02:28PM -0600, Lyndon Nerenberg wrote: > There is one problem with the /usr/bin/perl redirector: it can > cause autoconfiguration scripts to mistakenly think perl is > installed on the system (they find the /usr/bin/perl wrapper) when > it isn't (there is no perl-from-ports backing the redirector). An auto-configuration script which merely checks for the existance of a file rather than actually testing it's the file it needs is a bit silly and probably deserves the breakage. -- Jonathan Perkin - BBC Internet Services - http://support.bbc.co.uk/ Please check email headers for complete list of contact details To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Something probably trivial
I'm doing a cross-build of current on a system running stable, with a separate drive for current mounted as /current (with all sub-mounts correct). Separate problem causing me to cross-build: current doesn't like to boot lately - it hangs immediately after loading acpi.ko (on the SMP Supermicro; works fine on an Asus KT133A with older Athlon 1.2). I have been using setenv DESTDIR /current make -m/current/usr/share/mk -DDESTDIR=/current world >& mkw.out with mostly success (I only had to add the -m option lately and only for the kernel build so far, but I do it anyhow). The redundant DESTDIR is probably not needed but I want to be sure. After discovering the -j thing and its workaround independently, I now get the following stop after the initial compiler and lib build: >>> stage 4: populating /usr/obj/current/usr/src/i386/usr/include -- cd /current/usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/current/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/current/usr/src/i386/usr/libdata/perl/5.6.1 GROFF_BIN_PATH=/usr/obj/current/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/current/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/current/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/current/usr/src/i386 INSTALL="sh /current/usr/src/tools/install.sh" PATH=/usr/obj/current/usr/src/i386/usr/sbin:/usr/obj/current/usr/src/i386/usr/bin:/usr/obj/current/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks includes incsinstall make: don't know how to make includes. Stop *** Error code 2 Stop in /current/usr/src. *** Error code 1 Stop in /current/usr/src. --- A quick look at the makefiles doesn't show anything obvious; is is possible that DESTDIR is being used to look up OBJDIR sometimes (like where includes come from?) My /obj is shared with stable with no conflict since the leading subdir is current instead of usr... I'm going to try setting MAKEOBJDIRPREFIX to /current/usr/obj and see. Got the same failure at the same place. Can't find anything in the handbook about cross-builds; the makefiles are fairly clear but not all of the interactions of bsd.*.mk are obvious. Whatever changed did so in the last 2 or 3 weeks and may or may not be related to the cc change. The default gnu makefiles and dir setup for gmp won't build with -j either, just for info - they do mkdir in the middle of the make and assume all the resulting dependencies will be picked up. May work with gmake and -j but certainly not with bmake. -- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sbin/newfs newfs.8 newfs.c
On 2002-05-13 10:12, Mikhail Teterin wrote: > On Friday 10 May 2002 03:35 pm, Giorgos Keramidas wrote: > = On 2002-05-02 23:06, Makoto Matsushita wrote: > = > > = > Mikhail.Teterin> BTW, whatever became of the effort to make a > = > Mikhail.Teterin> wrapper called mount_mfs? > = > > = > See mdmfs(8). It was been there since Jun/2001 (about 10 months > = > ago). > = > = By casully skimming through the text of mdmfs(8) I don't see how it > = could be used to mount an MFS filesystem from fstab though :/ > > It could be -- by making a mount_mfs a symlink to mdmfs. That was the > compromise agreed on :-\ Ah yes. I see it now. But I'll try to come up with a way to make this clear in the manpage too. Or as [EMAIL PROTECTED] likes saying, "make it impossible to misunderstand". -- Giorgos Keramidas- http://www.FreeBSD.org [EMAIL PROTECTED] - The Power to Serve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The future of perl on FreeBSD
> "Jonathan" == Jonathan Perkin <[EMAIL PROTECTED]> writes: Jonathan> An auto-configuration script which merely checks for the Jonathan> existance of a file rather than actually testing it's the Jonathan> file it needs is a bit silly and probably deserves the Jonathan> breakage. And just what else besides Perl would you expect to find in /usr/bin/perl you silly pedant?!? ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The future of perl on FreeBSD
On Mon, May 13, 2002 at 02:45:09PM -0600, Lyndon Nerenberg wrote: > > "Jonathan" == Jonathan Perkin <[EMAIL PROTECTED]> writes: > > Jonathan> An auto-configuration script which merely checks for the > Jonathan> existance of a file rather than actually testing it's the > Jonathan> file it needs is a bit silly and probably deserves the > Jonathan> breakage. > > And just what else besides Perl would you expect to find in > /usr/bin/perl you silly pedant?!? ;-) A broken symlink? Perl 4? Perl 6? A perfectly reasionable wrapper script? If these programs detect perl and don't work because the wrapper is there, then a) they are broken and b) it will only take a couple minutes to fix by adding a perl package so why worry. /usr/bin/perl should work if perl is installed to avoid a massive POLA violation. Since ports must not touch /usr/bin and we must not assume that PREFIX=/usr/local, a symlink is out of the question. A wrapper isn't really going to cost us anything performance wise and allows the possability of providing something more useful then "File not found" as an error message. As such, it's a very good solution. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg38295/pgp0.pgp Description: PGP signature
Re: GCC-3.1 Optimization -Os broken
On Mon, May 13, 2002 at 09:57:08PM +0200, Daniel Rock wrote: > - recompile libalias with -Os => NAT broken > - recompile libalias with -O => NAT works again. > > I know any other optimization than -O isn't supported but this bug > (either in libalias or in gcc) should be investigated. If you could use bisetcion to track down this bug, then the gcc developers would probably be interested. Can you try recompiling just libalias with -Os and see if the problem returns? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The future of perl on FreeBSD
On Mon, May 13, 2002 at 02:45:09PM -0600, Lyndon Nerenberg wrote: > > "Jonathan" == Jonathan Perkin <[EMAIL PROTECTED]> writes: > > Jonathan> An auto-configuration script which merely checks for the > Jonathan> existance of a file rather than actually testing it's the > Jonathan> file it needs is a bit silly and probably deserves the > Jonathan> breakage. > > And just what else besides Perl would you expect to find in > /usr/bin/perl you silly pedant?!? ;-) A perl wrapper? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
On Sun, May 12, 2002 at 11:27:42PM +0200, Poul-Henning Kamp wrote: > > That one's easy to diagnose: > > You change your windowsize while tcsh happened to be in free(3) (frame #12). I've been seeing malloc crashes in tcsh as well, but not in the same codepath (they occur during a 'cd' operation). I have a crashdump somewhere but I can't find it at the moment :( Kris msg38298/pgp0.pgp Description: PGP signature
Re: The future of perl on FreeBSD
Jonathan Perkin wrote: > On Mon May 13, 2002 at 02:02:28PM -0600, Lyndon Nerenberg wrote: > > There is one problem with the /usr/bin/perl redirector: it can > > cause autoconfiguration scripts to mistakenly think perl is > > installed on the system (they find the /usr/bin/perl wrapper) when > > it isn't (there is no perl-from-ports backing the redirector). > > An auto-configuration script which merely checks for the existance > of a file rather than actually testing it's the file it needs is a > bit silly and probably deserves the breakage. FWIW: All the ones I have lying around that care about perl try to get the version by running it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GCC-3.1 Optimization -Os broken
In article <[EMAIL PROTECTED]> you write: > found the bug: -Os compilation seems broken with gcc-3.1. I normally > [...] I know any other optimization than -O isn't supported but this bug > (either in libalias or in gcc) should be investigated. I can narrow it down *much* further to exact small test cases. FYI, there are 8 C failures in the gcc 3.1 testsuite for FreeBSD/i386: 4 involve -Os (Quite sorry I never got around to fixing them before the release; I don't usually do per-CPU fixes but I could have requested help from the people that do.) 4 involve -Wformat checking not working in all cases (vfscanf only and then again only when not using the proper system headers; the test cases attempt to declare the prototypes). There are 2 C++ failures (only one of which is seen without linking against -lc_r); neither are extremely important. See http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00412.html http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00458.html FreeBSD/alpha is looking almost as good (more libgcj failures) http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00455.html http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00425.html Regards, Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GCC-3.1 Optimization -Os broken
On Mon, May 13, 2002 at 07:47:42PM -0500, Loren James Rittle wrote: > I can narrow it down *much* further to exact small test cases. FYI, > there are 8 C failures in the gcc 3.1 testsuite for FreeBSD/i386: > > 4 involve -Os (Quite sorry I never got around to fixing them > before the release; I don't usually do per-CPU fixes but I That's OK. :-) Your work with the C++ libs and Java libs on FreeBSD has been tremendous. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The future of perl on FreeBSD
On Mon, 13 May 2002, Jonathan Perkin wrote: > On Mon May 13, 2002 at 02:02:28PM -0600, Lyndon Nerenberg wrote: > > There is one problem with the /usr/bin/perl redirector: it can > > cause autoconfiguration scripts to mistakenly think perl is > > installed on the system (they find the /usr/bin/perl wrapper) when > > it isn't (there is no perl-from-ports backing the redirector). > > An auto-configuration script which merely checks for the existance > of a file rather than actually testing it's the file it needs is a > bit silly and probably deserves the breakage. There's two sides to this. One side is that you should always adhere to the FreeBSD filesystem standard. The other side is that if /usr/bin/perl exists it should always be a working perl program. I'd like to throw out a mention that I think that all filesystem standards imposed by the people writing the OS or the software packages and not imposed by the system administrators is the wrong way to go. A somewhat rambling stream-of-consciousness argument that I wrote about this is here: http://www.scriptkiddie.org/rants/registry.html I've been thinking that an interesting project would be to implement the "simple" part of this with the hooks into autoconf and /usr/bin/install and convert the FreeBSD base OS to use it. I'll be doing that after someone can roll the clock back to 1999 and have my stock options hit 200 though... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Automated reply from sattle@mail.sat50.com
Thanks for your inquiry. We will respond to your email in the order that it was received. Sattle http://www.sat50.com <-- This is an automated response --> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /tmp/des/obj/i386/d/home/des/tinderbox/src/i386/usr/include -- >>> stage 4: building libraries -- ===> kerberosIV/lib/libkdb ... /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 1 of `des_pcbc_encrypt' from incompatible pointer type /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 2 of `des_pcbc_encrypt' from incompatible pointer type /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c: In function `kdb_encrypt_key': /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 1 of `des_pcbc_encrypt' from incompatible pointer type /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 2 of `des_pcbc_encrypt' from incompatible pointer type ===> kerberosIV/lib/libkrb ===> kerberosIV/lib/libtelnet cc1: warnings being treated as errors /d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c: In function `kerberos4_cksum': /d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c:496: warning: unreachable code at beginning of switch statement *** Error code 1 Stop in /d/home/des/tinderbox/src/kerberosIV/lib/libtelnet. *** Error code 1 Stop in /d/home/des/tinderbox/src/kerberosIV/lib. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installworld problem with /usr/src/usr.bin/tip/tip
On Mon, 13 May 2002, David W. Chapman Jr. wrote:
> I get the following everytime I make installworld on -current
>
> ln: /usr/bin/cu: Operation not permitted
> *** Error code 1
>
> To fix it I have to modify /usr/src/usr.bin/tip/tip/Makefile and
> remove the LINKS to cu and then all works well. Is anyone else
> having this problem?
This seems to be because you have an old /usr/bin/cu with the schg set
on it, and rev.1.17 of the Makefile broke the unsetting of the schg
bit (${DESTDIR}/${BINDIR}/cu rarely exists, becuase BINDIR is used
before it is initialized).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make includes
[CC: to -current as others may benefit from it too] On Mon, May 13, 2002 at 08:33:31PM +0200, Anders Andersson wrote: > Hi, > > I write to you since you have been touching src/Makefile alot and so on. > > I sometimes want a fresh /usr/include and wipes it and does a: > > cd /usr/src && make includes > > but that does not work anymore! > > It seems that it does the correct thing but not a single file is > installed in /usr/include > > Do you have any clue whats going on? > Yes. "make includes" has been modified to mean "build includes", and the new "make incsinstall" has been added to "install" them. So the correct sequence is "make includes incsinstall". I'm still unsure about the name; I'd have liked to rename it to "includesinstall" but that is too long. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38306/pgp0.pgp Description: PGP signature
Re: make includes
On 14-May-2002 (06:21:18/GMT) Ruslan Ermilov wrote:
> I'm still unsure about the name; I'd have liked to rename it to
> "includesinstall" but that is too long.
U, buildworld, installworld, buildkernel, installkernel...
It would be: buildinclude{s}, installinclude{s} just to be simmetric :)
And is only one (or two) character longer than installkernel...
my .02 EUR
Riccardo.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: makefiles broken with make -j?
On Mon, May 13, 2002 at 08:41:11PM +0200, John Hay wrote:
> Hi,
>
> It looks like the makefiles are a bit broken if make -j13 is used. What
> I see here is that osreldate.h in obj/usr/src/i386/usr/include/ looks
> like this:
>
>
> ...
> #ifdef _KERNEL
> #ifdef _KERNEL
> #error "/usr/include/osreldate.h cannot be used in the kernel, use sys/param.h"
> #error "/usr/include/osreldate.h cannot be used in the kernel, use sys/param.h"
> #else
> #else
> #undef __FreeBSD_version
> #undef __FreeBSD_version
> #define __FreeBSD_version 500035
> #define __FreeBSD_version 500035
> #endif
> #endif
>
>
> When looking at the output of "make -j13 world", it looks like some parts
> are being run more than once:
>
>
> --
> >>> stage 4: populating /usr/obj/usr/src/i386/usr/include
> --
> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORM
> AT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/li
> bdata/perl/5.6.1 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=
> /usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i38
> 6/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/inst
> all.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/
> obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 S
> HARED=symlinks includes incsinstall
> ===> share/info
> ===> share/info
> ===> include
> ===> include
> Setting up symlinks to kernel source tree...
>
>
I also see the breakage with -j8 "make release", but in a different place,
while building "krb5" dist. I'm currently testing this patch.
%%%
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.273
diff -u -r1.273 Makefile.inc1
--- Makefile.inc1 12 May 2002 16:00:43 - 1.273
+++ Makefile.inc1 14 May 2002 06:32:01 -
@@ -299,7 +299,7 @@
@echo "--"
@echo ">>> stage 4: populating ${WORLDTMP}/usr/include"
@echo "--"
- cd ${.CURDIR}; ${WMAKE} SHARED=symlinks includes incsinstall
+ cd ${.CURDIR}; ${WMAKE} includes; ${WMAKE} SHARED=symlinks incsinstall
_libraries:
@echo
@echo "--"
%%%
Now I know why running "make all install" is not a good idea (in the -j
case). ``.ORDER: all install'' or ``.ORDER: includes incsinstall'' do not
work because these do not cause the necessary ordering for sub-dependents.
What I mean here is that:
all: ${PROG} ${SCRIPTS} ${FILES} _includes _manpages
install: realinstall
realinstall: _proginstall _scriptsinstall _filesinstall _incsinstall _maninstall
And ``.ORDER: all install'' does not cause e.g. _includes and _incsinstall
to be run in sequence.
One might now wonder why not fix it like this:
.ORDER: _includes _incsinstall
The answer is that makefiles are allowed to redefine "includes" and/or
"incsinstall". In that case, _includes and/or _incsinstall won't even
be defined, and we'd now have to make sure (in this particular makefile)
that "make includes incsinstall" works in -j case by providing the
necessary .ORDER'ing, while not running "making" and "installing" parts
together in the -j case will "just work".
Bruce, yes I am aware of the problem with _incsinstall attempting to
"make" includes if they are not built.
I even attempted to fix it like this:
%%%
.if exists(${file})
_fooinstall: _fooinstall_${file}
_fooinstall_${file}: ${file}
${INSTALL} ${.ALLSRC} ...
.endif
%%%
But this unfortunately breaks the common "make all install" case, which
is (as should be apparent from the previous paragraph) is just wrong in
the -j case.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg38308/pgp0.pgp
Description: PGP signature
Re: make includes
On Tue, May 14, 2002 at 08:45:59AM +0200, Riccardo Torrini wrote:
> On 14-May-2002 (06:21:18/GMT) Ruslan Ermilov wrote:
>
> > I'm still unsure about the name; I'd have liked to rename it to
> > "includesinstall" but that is too long.
>
> U, buildworld, installworld, buildkernel, installkernel...
> It would be: buildinclude{s}, installinclude{s} just to be simmetric :)
> And is only one (or two) character longer than installkernel...
>
Then "all" should similarly be renamed to "build". I like the idea
of consistent naming. It's a pity we don't have synonyms in make(1).
build: buildprogram buildscripts buildfiles buildmanpages buildincludes
Then s/build/install/g.
"build" should probably be left as "all" for compatibility, I'm not sure.
Then we could say that we reserve target names "all.*" and "install.*",
to avoid possible clashes.
I will see if I can implement something like that in a long term.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg38309/pgp0.pgp
Description: PGP signature
