Akim Demaille <[EMAIL PROTECTED]> wrote:
| >>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
| Alexandre> On Nov 30, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
| >> | +./configure: 24794 Alarm call
|
| >> This is why it failed: the shell complains of the signal it
| >> received. I don't know how to address this issue.
...
| Jim, Paul, you two guys certainly know very well the mktime test.
| How come the alarm was still set?
Do you mean why did was the code still running 60 seconds
after it started? Because that system has a rotten mktime implementation.
| And why is it
| the shell that received it (Ahem, my Unix knowledge is not too good...).
Because the program didn't handle SIGALRM itself.
| How would you fix it?
[ I haven't looked at the test suite code that tests AC_FUNC_MKTIME.
I presume that by `it' you mean the macro itself, and not the testing
framework. ]
One way would be to install a signal handler for SIGALRM
and then exit nonzero from the handler.
But that might be a little too involved a change to make this close
to a test release. Especially considering that this happens only on
systems with a broken mktime function. At worst, all it does is cause
a little confusion among the few users who actually pay attention to
the output of running configure on a losing system.
