On Mon, Nov 18, 2002 at 12:24:51PM +0100, Miguel Mendez wrote:
> See attached patch, haven't tested on -STABLE tho, sorry, only have -CURRENT now.
Committed, thanks!
Kris
msg47366/pgp0.pgp
Description: PGP signature
On Mon, Nov 18, 2002 at 02:43:28AM -0800, Kris Kennaway wrote:
> http://bento.freebsd.org/errorlogs/5-latest/icecast-1.3.12_1.log
>
> cc -DHAVE_CONFIG_H -I. -I. -I.. -D_REENTRANT -I/usr/include/readline -pthread
> threads.c: In function `thread_block_signals':
> threads.c:467: `SIGBUS' undeclar
http://bento.freebsd.org/errorlogs/5-latest/icecast-1.3.12_1.log
cc -DHAVE_CONFIG_H -I. -I. -I.. -D_REENTRANT -I/usr/include/readline -pthread
threads.c: In function `thread_block_signals':
threads.c:467: `SIGBUS' undeclared (first use in this function)
threads.c:467: (Each undeclared identifier
On Mon, 30 Sep 2002, Juli Mallett wrote:
>
> Teh same that provides specification for queued signals - posix rts.
hey that's MY typo... get your own! :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
* De: Julian Elischer <[EMAIL PROTECTED]> [ Data: 2002-09-30 ]
[ Subjecte: Re: signal changes ]
>
>
> On Mon, 30 Sep 2002, Juli Mallett wrote:
>
> > * De: Julian Elischer <[EMAIL PROTECTED]> [ Data: 2002-09-30 ]
> > [ Subjecte: Re: signal change
On Mon, 30 Sep 2002, Juli Mallett wrote:
> * De: Julian Elischer <[EMAIL PROTECTED]> [ Data: 2002-09-30 ]
> [ Subjecte: Re: signal changes ]
> >
> > On Mon, 30 Sep 2002, Juli Mallett wrote:
> >
> > > > What limits are the on the number of si
David Scheidt wrote:
>
> On Tue, 23 Nov 1999, David O'Brien wrote:
>
> > > Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current
> > > buildworld running on an older -current system now progresses much
> > > further - in fact it now completes :-).
> >
> > Actually, I've been seeing
Mark Murray wrote:
>
> > I'm not sure how to fix this problem. Unlike our other build tools,
> > perl is not designed to be able to be cross-built: It builds bits
> > of itself and assumes they can be safely executed to build other bits.
>
> Perl is hugely fragile; cross-building it is a big P
> I'm not sure how to fix this problem. Unlike our other build tools,
> perl is not designed to be able to be cross-built: It builds bits
> of itself and assumes they can be safely executed to build other bits.
Perl is hugely fragile; cross-building it is a big PITA. If you
have any smart ideas
On Tue, 23 Nov 1999, David O'Brien wrote:
> > Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current
> > buildworld running on an older -current system now progresses much
> > further - in fact it now completes :-).
>
> Actually, I've been seeing just the opposite.
> Before you could
> Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current
> buildworld running on an older -current system now progresses much
> further - in fact it now completes :-).
Actually, I've been seeing just the opposite.
Before you could build a -CURRENT kernel and then the world. Now those
Peter Jeremy writes:
| Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current
| buildworld running on an older -current system now progresses much
| further - in fact it now completes :-).
|
| There are, however still a few problems - as far as I can tell, these
| are all related to t
Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current
buildworld running on an older -current system now progresses much
further - in fact it now completes :-).
There are, however still a few problems - as far as I can tell, these
are all related to the wrong version of perl being ca
Peter Wemm wrote:
>
> Before getting too far here, can we consider some other standard interfaces?
>
> #include
>
> int getcontext(ucontext_t *ucp);
> int setcontext(const ucontext_t *ucp);
> void makecontext(ucontext_t *ucp, (void *func)(), int argc, ...);
> int swapc
Marcel Moolenaar wrote:
> Garrett Wollman wrote:
> >
> > < said
:
> >
> > > The setjump/longjump family of functions are userland function
> > > AFAICT.
> >
> > POSIX doesn't make any such distinction. Remember that setjmp/longjmp
> > *already* enter the kernel, in order to save/restore th
Garrett Wollman wrote:
>
> < said:
>
> > The setjump/longjump family of functions are userland function
> > AFAICT.
>
> POSIX doesn't make any such distinction. Remember that setjmp/longjmp
> *already* enter the kernel, in order to save/restore the signal mask,
> so there isn't any real perfor
< said:
> The setjump/longjump family of functions are userland function
> AFAICT.
POSIX doesn't make any such distinction. Remember that setjmp/longjmp
*already* enter the kernel, in order to save/restore the signal mask,
so there isn't any real performance penalty! (Programs which need a
che
17 matches
Mail list logo
