Perl guesses wrong for signals using linux 2.1.xx headers

David Dyck (dcd@TC.FLUKE.COM)
Thu, 19 Mar 1998 10:25:19 -0800


I've been trying to use the latest perl, and also the latest
linux releases. I was suprised that a 'simple' (not really)
bug that affects few linux users, cause perl's configure
to break.

Basically, the linux kernel 2.1.x headers work for most
things, but they haven't provided a valid SIGRTMAX,
as the following C program doesn't compile

#include <signal.h>

#include <stdio.h>
int main() {
printf("SIGRTMAX=%d\n", SIGRTMAX);
}

-----------------

The problem is, they do define
#define SIGRTMAX (_NSIG-1)
but they didn't want users go
get at the value of _NSIG, so there
is an #ifdef __KERNEL__ around its
definition.

(I've posted this to the linux kernel mail list
but have had no response)

Anyway, when the signal test program provide by
metaconfig fails, Perl gets a 'very bad'
guess at the signal numbers, and things don't
work very will, to say the least.

Anyway, it was quite difficult to detect
that this was the problem, as I normally run
Configure -d, and the hint a a compile error
just flys by.

1)
I think that there should be a better way
to notify the user of a compile error

2)
It would be better if Configure could try
to verify that it's guesses were correct,
as it just auto numbers them -- very bad!

3)
It was also difficult to extract the C
signal test program that failed, which made
it difficult do diagnose as well.
I would like to look into ways to keep the
test scripts and program around for the
user to look into when there was a compile error.

[ perhaps adding a flag to go interactive on
compile errors, and allow me to get at
the failing files (and the environments
passed to them) would solve part of the problem ]

I'm just begging to think of looking into metaconfigure
and trying to find a way to enhance the signal tests.

I solicit your advice on this matter.

David Dyck

PS. I've included my posting to the perl5 porters
mailing list, but the only response I got was
"avoid linux 2.1"

---------- Forwarded message ----------
Date: Fri, 13 Mar 1998 11:45:09 -0800 (PST)
From: David Dyck <dcd@tc.fluke.com>
To: "Kurt D. Starsinic" <kstar@chapin.edu>
Cc: domo@vo.lu, perl5-porters@perl.org
Subject: BUG in 5.004_62: Perl guesses wrong for signals using linux 2.1.xx headers: Was Pipes failing with new perl's > 5.004_54

It seems that when the perl is configured using
recent linux kernel headers files 2.1.x,
it can't create the signal names and numbers.

(I've been using Configure -d for so long that
this error just flew by.

/---------------------------------------------------------------------\
| Generating a list of signal names and numbers... |
| (I can't seem be able to compile the test program -- Guessing) |
| The following signals are available: |
| |
| SIGZERO SIGHUP SIGINT SIGQUIT SIGILL SIGTRAP SIGIOT SIGFPE SIGKILL |
| SIGUSR1 SIGSEGV SIGUSR2 SIGPIPE SIGALRM SIGTERM SIGCHLD SIGCONT |
| SIGSTOP SIGTSTP SIGTTIN SIGTTOU SIGWINCH |
\---------------------------------------------------------------------/

1) would like to suggest that since this guess is wrong on
linux, and may be wrong elsewhere, that if Configure include
some record that it guessed in config.sh, and it would
be nice if it saved the scripts that were used .c file so
someone could diagnose the problem better.

2)
I noticed that the guessing code uses csh to extract the signal names
and csh reports kill -l on my system as
HUP INT QUIT ILL TRAP IOT FPE KILL USR1 SEGV USR2 PIPE ALRM TERM CHLD CONT STOP TSTP TTIN TTOU WINCH
but I was really surprised that Configure then numbered the signals in incrementing
order. This is a bad guess in my case

the bash builtin kill reports
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE
9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2
13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD
18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN
22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO
30) SIGPWR

3) when I finally extracted the failing signal.c test program I
got the compile error

signal.c: In function `main':
signal.c:124: `_NSIG' undeclared (first use this function)
signal.c:124: (Each undeclared identifier is reported only once
signal.c:124: for each function it appears in.)

Looking at the comments in
/usr/src/linux-2.1.89/include/asm-i386/signal.h
leads me to believe that the kernel authors don't
want folks to use _NSIG, but rather the
#define NSIG 32

4) I've spent too much time on this already, and I am convinced that
it is a perl problem, and not a linux kernel 2.1.x problem.

I await the groups advice....

David Dyck

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu