On Fri, 19 Aug 2005, David Dyck wrote:
> > Yes. This is an older libc5 base 'slackware' system with
> > a 2.4.32-pre1 kernel that has had trouble with signals
> > before. I think special code had been added to configure
> > to test all the signals individually. I was surprised when
> > these failures occured in the POSIX build - even though miniperl
> > build fine.
>
> Just wanted to collect some more info for this bug report
>
> The error
> const-c.inc:2010: `_NSIG' undeclared (first use in this function)
>
> is from the lines
>
> #ifdef SIGRTMAX
> *iv_return = SIGRTMAX;
> return PERL_constant_ISIV;
> #else
> return PERL_constant_NOTDEF;
> #endif
>
> where my <asm/signal.h> (inherited libc5 style
> from the 2.4 kernel sources) has SIGRTMAX
>
> /* These should not be considered constants from userland. */
> #define SIGRTMIN 32
> #define SIGRTMAX (_NSIG-1)
In newer glibc2-based systems, SIGRTMAX is defined to be a C library
function: __libc_current_sigrtmax().
> but _NSIG is only defined when compiling the kernel (#ifdef __KERNEL__)
only on such hybrid 2.4.x/libc5 systems, I'd bet. I'd call this a bug in
the headers, but we should still work around it.
Yes, Configure has previously tested each individual signal, but it's not
stored as a really simple config.h #ifdef. One could do a runtime lookup
for the string "RTMAX" in the sign_name[] array, I suppose. It'd probably
work just as well to change the test to something like the following to
ensure that SIGRTMAX is indeed set to something numeric.
#if defined(SIGRTMAX) && SIGRTMAX > SIGRTMIN
--
Andy Dougherty [EMAIL PROTECTED]
