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: http://www.Baldwin.cx/~john/pgpke
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 o
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 __Fr
"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
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 o
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,
> > y
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 /usr/src/lib/libc_r/../libc/stdtime/localtime.
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 a
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
ne
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.
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
* 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 rebuil
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 fre
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
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
> 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 f
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 t
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:
-
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
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 n
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 -l
* 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 l
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
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
:
: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 th
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.
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 por
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 -D_KERNE
"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
> ne
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
>-I../
> 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 th
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 r
"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
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
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 would
> for a threaded application on just about any other OS (only
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
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 nee
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: mutex_e
===> 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
lib/a
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 DUMMYN
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 DUMM
41 matches
Mail list logo
