This is a known problem in the SF code that Paul is trying to work through.
Here is a description (from Paul, in previous emails with me) on this point:
The portability problem should not be unique to the SF code. On line
242 of the module OPS.pm in version 2.49 of the supported code:
sigaction SIGALRM, new POSIX::SigAction( 'OPS::alrm_handler' );
alarm( $timeout );
On line 164 of the module OPS::Sock of version 1.53 of the SF code:
sigaction SIGALRM, new POSIX::SigAction('Sock::alrm_handler');
return alarm($timeout);
Both utilize POSIX in an attempt to have a portable signal handling
mechanism. Unfortunately, some systems claim POSIX compliance, but
fall short.
There's a solution out there, I just haven't tracked it down yet...
If any NT programming guru's have some input, it would be greatly
appreciated :)
Charles Daminato
OpenSRS Product Manager
Tucows Inc. - [EMAIL PROTECTED]
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of John W. Roche IV
> Sent: February 20, 2002 10:22 AM
> To: [EMAIL PROTECTED]
> Subject: SIGALRM
>
>
> An Application Error Has Occurred
> Your request could not be completed because the following error
> has been reported:
>
> Internal Error: Your vendor has not defined POSIX macro SIGALRM,
> used at C:/Webs/OpenSRSsf/lib/OPS/Sock.pm line 164
> If you require further assistance, or if you believe you have
> received this message in error, please contact undefined.
>
> This only occurs in the latest SF version, yet the code exists in
> both current versions. Perhaps the OpenSRS version does not
> actually call this function? Is anyone else seeing this on Win32?
>
> John W Roche
> eInfosystems.net
