HEADS UP: current broken for a while

2001-01-24 Thread John Baldwin
I'm committing another big wad of code that all depends on each other, so -current kernels are going to be broken for a while. I'll send another mail when it is back to working again. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key:

Re: strong recommendation re: NFS

2001-01-24 Thread Ronald van der Pol
On Sun, 21 Jan 2001, Matt Dillon wrote: Concentrate on making the general network stack (aka TCP) and filesystems SMP aware. Leave NFS alone for now. Please. If I understand correctly another item on the wishlist is TI-RPC (so that NFS can be made IPv6 aware). What is the latest on

HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Daniel M. Eischen
As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild them without the -pthread option using -lc_r. For porters, the

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Maxim Sobolev
"Daniel M. Eischen" wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild them without the -pthread option

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Jason Evans
On Wed, Jan 24, 2001 at 03:37:24PM +0200, Maxim Sobolev wrote: "Daniel M. Eischen" wrote: For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. Could you please bump version number of libc/libc_r shared libraries, so the programs linked with older

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Daniel Eischen
On Wed, 24 Jan 2001, Maxim Sobolev wrote: "Daniel M. Eischen" wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll

help!

2001-01-24 Thread Rasa Karapandza
I just downloaded src-cur.4700xEmpty.gz src-cur.4701 src-cur.4702 removed my old source tree installed them using CTM when trying to make world I get an error lib/libc_r/../libc/stdtime/localtime.c -o localtime.o In file included from

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Maxim Sobolev
Daniel Eischen wrote: On Wed, 24 Jan 2001, Maxim Sobolev wrote: "Daniel M. Eischen" wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built

RE: HEADS UP: current broken for a while

2001-01-24 Thread John Baldwin
On 24-Jan-01 John Baldwin wrote: I'm committing another big wad of code that all depends on each other, so -current kernels are going to be broken for a while. I'll send another mail when it is back to working again. Ok, it should be back to normal now. Sorry this took so long. Now I need

Re: HEADS UP: current broken for a while

2001-01-24 Thread Peter Wemm
John Baldwin wrote: On 24-Jan-01 John Baldwin wrote: I'm committing another big wad of code that all depends on each other, so -current kernels are going to be broken for a while. I'll send another mail when it is back to working again. Ok, it should be back to normal now. Sorry

Re: HEADS UP: current broken for a while

2001-01-24 Thread Warner Losh
In message [EMAIL PROTECTED] Peter Wemm writes: : Normal - as in "It compiles". I would *strongly* caution anybody (even : more so than usual) about using -current where a crash would be bad. A lot : of new stuff went in and INVARIANTS and WITNESS are still finding some edge : cases. The proc

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Alfred Perlstein
* Daniel M. Eischen [EMAIL PROTECTED] [010124 05:26] wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild

beware libc change sigprocmask sigaction abort.c

2001-01-24 Thread Mark Hittinger
Hey watch out - one of those little changes that can blow your system up if you cheat on how you build it. abort.c references undefined symbols for sigprocmask and sigaction. Later Mark Hittinger Earthlink [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Daniel Eischen
On Wed, 24 Jan 2001, Alfred Perlstein wrote: * Daniel M. Eischen [EMAIL PROTECTED] [010124 05:26] wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps

Re: [RFC] New features for libvgl

2001-01-24 Thread Nicolas Souchu
On Mon, Jan 22, 2001 at 08:45:19PM +0200, Maxim Sobolev wrote: Hi folks, Now I'm in process of writing a libvgl driver for SDL (almost finished - I'm testing it right now) and found that two handy features are currently missed from the libvgl: ability to query video modes supported by the

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Jordan Hubbard
What's not clear ;-) Use -lc_r instead of -pthread. gcc -Wall -o foo foo.c -lc_r The old way was: gcc -Wall -D_THREAD_SAFE -o foo foo.c -pthread H. And does the -pthread argument do anything anymore? If not, why not have it default to simply linking in libc_r for

status of bridge code

2001-01-24 Thread Rogier R. Mulhuijzen
Is anyone working on the bridge code? I've got a couple of things I'd like to fix in it, but I wouldn't want to be doing anything someone else already did. My wishlist: 1) Better interaction with various drivers (like if_tap). For some reason I need to do a wack (undocumented) sysctl to make

Please test this patch to restore cc -pthread

2001-01-24 Thread John Polstra
Here is a patch which should make "cc -pthread" work properly with Dan Eischen's recent libc libc_r changes. I'd appreciate it if some people running up-to-date -current would test it. I especially need testers who can use it to build some threaded applications. Recommended test procedure: -

Re: [RFC] New features for libvgl

2001-01-24 Thread Maxim Sobolev
Nicolas Souchu wrote: On Mon, Jan 22, 2001 at 08:45:19PM +0200, Maxim Sobolev wrote: Hi folks, Now I'm in process of writing a libvgl driver for SDL (almost finished - I'm testing it right now) and found that two handy features are currently missed from the libvgl: ability to query

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Daniel Eischen
On Wed, 24 Jan 2001, Jordan Hubbard wrote: What's not clear ;-) Use -lc_r instead of -pthread. gcc -Wall -o foo foo.c -lc_r The old way was: gcc -Wall -D_THREAD_SAFE -o foo foo.c -pthread H. And does the -pthread argument do anything anymore? If not, why not

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Dan Nelson
In the last episode (Jan 24), Daniel Eischen said: On Wed, 24 Jan 2001, Alfred Perlstein wrote: * Daniel M. Eischen [EMAIL PROTECTED] [010124 05:26] wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Alfred Perlstein
* Dan Nelson [EMAIL PROTECTED] [010124 10:32] wrote: In the last episode (Jan 24), Daniel Eischen said: On Wed, 24 Jan 2001, Alfred Perlstein wrote: * Daniel M. Eischen [EMAIL PROTECTED] [010124 05:26] wrote: As discussed a few days ago, I've just committed the changes to libc and

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Maxim Sobolev
Dan Nelson wrote: In the last episode (Jan 24), Daniel Eischen said: On Wed, 24 Jan 2001, Alfred Perlstein wrote: * Daniel M. Eischen [EMAIL PROTECTED] [010124 05:26] wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Daniel Eischen
On Wed, 24 Jan 2001, Dan Nelson wrote: In the last episode (Jan 24), Daniel Eischen said: On Wed, 24 Jan 2001, Alfred Perlstein wrote: * Daniel M. Eischen [EMAIL PROTECTED] [010124 05:26] wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow

Re: strong recommendation re: NFS

2001-01-24 Thread Matt Dillon
: :On Sun, 21 Jan 2001, Matt Dillon wrote: : : Concentrate on making the general network stack (aka TCP) and : filesystems SMP aware. Leave NFS alone for now. Please. : :If I understand correctly another item on the wishlist is TI-RPC :(so that NFS can be made IPv6 aware). What is the

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Dan Nelson
In the last episode (Jan 24), Maxim Sobolev said: Dan Nelson wrote: I thought the old way was just -pthread, and it would handle everything. I did a quick scan of the devel/ and net/ branches of our ports tree, and of 43 thread-using ports, 36 of the ports simply add -pthread. Only 7

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Maxim Sobolev
Dan Nelson wrote: In the last episode (Jan 24), Maxim Sobolev said: Dan Nelson wrote: I thought the old way was just -pthread, and it would handle everything. I did a quick scan of the devel/ and net/ branches of our ports tree, and of 43 thread-using ports, 36 of the ports simply

cy.c doesn't compile in LINT

2001-01-24 Thread Poul-Henning Kamp
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -DGPROF -DGPROF4 -DGUPROF

Re: status of bridge code

2001-01-24 Thread Julian Elischer
"Rogier R. Mulhuijzen" wrote: Is anyone working on the bridge code? I've got a couple of things I'd like to fix in it, but I wouldn't want to be doing anything someone else already did. My wishlist: 1) Better interaction with various drivers (like if_tap). For some reason I need to do

Re: cy.c doesn't compile in LINT

2001-01-24 Thread Jason Evans
On Wed, Jan 24, 2001 at 09:21:06PM +0100, Poul-Henning Kamp wrote: cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../../include

Re: status of bridge code

2001-01-24 Thread Thomas T. Veldhouse
Have a look at what you can do with netgraph first. Most people don't know what it is but it allows almost arbitrarily complicated network topologies to be set up from the command line. Is there any reasonable documentation or a HOWTO on the usage of netgraph? I am currently using the

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Warner Losh
In message [EMAIL PROTECTED] Alfred Perlstein writes: : -D_THREAD_SAFE used to (or still does) make various foo_r function : prototypes available. Currently it does not do this. The foo_r prototypes are always available. Well, when we aren't compiling _ANSI_SOURCE or _POSIX_SOURCE. Dan was

Re: status of bridge code

2001-01-24 Thread Julian Elischer
"Thomas T. Veldhouse" wrote: Have a look at what you can do with netgraph first. Most people don't know what it is but it allows almost arbitrarily complicated network topologies to be set up from the command line. Is there any reasonable documentation or a HOWTO on the usage of

Re: lastest kernel from cvs ( sh exists with signal 8 )

2001-01-24 Thread Marcel Moolenaar
John Baldwin wrote: What happened is that binutils was upgraded from 2.9 to 2.10 in both -current and -stable, and the old and new binutils weren't compatible. So, you had to installworld before building your kernel (which is what I did, and always do in fact). However, this made some

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Garrett Rooney
On Wed, Jan 24, 2001 at 07:07:20PM -0400, Craig Hawco wrote: On Wed, 24 Jan 2001, Daniel Eischen wrote: Using -pthread will prevent linking to libc and only link to libc_r. After the change I just committed, you need to link to both libc_r and libc (in that order), just like you

Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps

2001-01-24 Thread Craig Hawco
On Wed, 24 Jan 2001, Garrett Rooney wrote: On Wed, Jan 24, 2001 at 07:07:20PM -0400, Craig Hawco wrote: On Wed, 24 Jan 2001, Daniel Eischen wrote: Using -pthread will prevent linking to libc and only link to libc_r. After the change I just committed, you need to link to

panic in netgraph (caught by WITNESS) in custom UP kernel

2001-01-24 Thread Rogier R. Mulhuijzen
FYI: Full source CVSupped on the 18th or 19th Panic came about when I did a 'ls' in ngctl(8). Kernel config attached, gdb of core follows below: This GDB was configured as "i386-unknown-freebsd"... IdlePTD 5300224 initial pcb at 31c4e0 panicstr: from debugger panic messages: --- panic:

world dies in perl

2001-01-24 Thread Michael Harnois
=== gnu/usr.bin/perl/perl cc -O -pipe -march=i686 -I/usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5 -I/usr/obj/usr/src/gnu/usr.bin/perl/perl -DPERL_CORE -pthread -I/usr/obj/usr/src/i386/usr/include -Wl,-E -L/usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl -o perl perlmain.o

Re: status of bridge code

2001-01-24 Thread Archie Cobbs
Julian Elischer writes: Is there any reasonable documentation or a HOWTO on the usage of netgraph? I am currently using the standard bridging code and IPFIREWALL (ipfw) with my dc cards. No problems so far - as long as I don't use DUMMYNET with it. I really wish I could use DUMMYNET as I

Re: status of bridge code

2001-01-24 Thread Doug White
On Wed, 24 Jan 2001, Archie Cobbs wrote: Julian Elischer writes: Is there any reasonable documentation or a HOWTO on the usage of netgraph? I am currently using the standard bridging code and IPFIREWALL (ipfw) with my dc cards. No problems so far - as long as I don't use DUMMYNET with