Daniel Eischen eisc...@vigrid.com writes:
Just tell me what to do, and I'll do it :-)
I won't go that far, but I'd suggest keeping the versions in -current
and -stable in sync (after testing new stuff in -current, of
course). There's (yet) no technical reason not to do so and it makes
Thomas Gellekum [EMAIL PROTECTED] wrote:
Daniel Eischen [EMAIL PROTECTED] writes:
There are some bugs in libc_r in stable that have been fixed in
-current. I think the one that you've hit is an uninitialized
TAILQ_HEAD in a statically declared mutex (in localtime). It's
probably
Daniel Eischen [EMAIL PROTECTED] writes:
The libc_r version number was bumped in -current because of the
addition of poll(). Is this allowed in -stable, or something
that waits for a -RELEASE?
Jordan should have to say something about this. AFAIR, bumps are
allowed but only by one between
On Thu, 15 Jul 1999, Jordan K. Hubbard wrote:
:- Jordan should have to say something about this. AFAIR, bumps are
:- allowed but only by one between releases. We will have to provide
:- libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this
:- anyway by the time 4.x is released).
Jordan should have to say something about this. AFAIR, bumps are
allowed but only by one between releases. We will have to provide
libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this
anyway by the time 4.x is released).
I'd prefer not to bump it... John Birrell and
Daniel Eischen eisc...@vigrid.com writes:
There are some bugs in libc_r in stable that have been fixed in
-current. I think the one that you've hit is an uninitialized
TAILQ_HEAD in a statically declared mutex (in localtime). It's
probably about time for a MFC. If someone wants to give me
Thomas Gellekum t...@ihf.rwth-aachen.de wrote:
Daniel Eischen eisc...@vigrid.com writes:
There are some bugs in libc_r in stable that have been fixed in
-current. I think the one that you've hit is an uninitialized
TAILQ_HEAD in a statically declared mutex (in localtime). It's
Daniel Eischen eisc...@vigrid.com writes:
The libc_r version number was bumped in -current because of the
addition of poll(). Is this allowed in -stable, or something
that waits for a -RELEASE?
Jordan should have to say something about this. AFAIR, bumps are
allowed but only by one between
Thomas Gellekum t...@ihf.rwth-aachen.de writes:
libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this
/usr/src/lib/compat/compat3x
Sorry.
tg
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Jordan should have to say something about this. AFAIR, bumps are
allowed but only by one between releases. We will have to provide
libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this
anyway by the time 4.x is released).
I'd prefer not to bump it... John Birrell and I are
On Thu, 15 Jul 1999, Jordan K. Hubbard wrote:
:- Jordan should have to say something about this. AFAIR, bumps are
:- allowed but only by one between releases. We will have to provide
:- libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this
:- anyway by the time 4.x is released).
Jordan should have to say something about this. AFAIR, bumps are
allowed but only by one between releases. We will have to provide
libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this
anyway by the time 4.x is released).
I'd prefer not to bump it... John Birrell and I
I don't care one way or the other. I could leave out the wrapped
poll() very easily and avoid the issue all together. This would
provide -stable with everything -current has, except of course
poll(). I'd prefer to add poll, though...
I'm OK with adding poll(), it just seemed odd that the
Kip Macy wrote:
In the mean time, you can grab libc_r/uthread/* from -current
and rebuild libc_r under -stable.
Yes, I am running -stable. I did upgrade my libc_r a few weeks ago as a
result of a problem with infinite recursion in write. When was this bug
fixed?
The fix for static
Daniel Eischen [EMAIL PROTECTED] writes:
There are some bugs in libc_r in stable that have been fixed in
-current. I think the one that you've hit is an uninitialized
TAILQ_HEAD in a statically declared mutex (in localtime). It's
probably about time for a MFC. If someone wants to give me
Can someone familiar with the new threads code tell me what is causing the
following segmentation fault. Thanks.
-Kip
Program terminated with signal 11, Segmentation fault.
#0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00)
at
Can someone familiar with the new threads code tell me what is causing the
following segmentation fault. Thanks.
-Kip
Program terminated with signal 11, Segmentation fault.
#0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00)
at
On Wed, 14 Jul 1999, Daniel Eischen wrote:
Can someone familiar with the new threads code tell me what is causing the
following segmentation fault. Thanks.
-Kip
Program terminated with signal 11, Segmentation fault.
#0 0x82fb15d in
Kip Macy wrote:
In the mean time, you can grab libc_r/uthread/* from -current
and rebuild libc_r under -stable.
Yes, I am running -stable. I did upgrade my libc_r a few weeks ago as a
result of a problem with infinite recursion in write. When was this bug
fixed?
The fix for static
19 matches
Mail list logo
