> Here's a patch against today's snapshot of head.
>>> I think that you has to compile with -DWIN32_LEAN_AND_MEAN in
>>> Configure before to do some undefs in openssl headers.
> I'm not really convinced, but for the time being, I've added that
> compile
> option to get rid of that more or less cosmetic issue.
> Apart from adding a line to configure, I needed a slight modification
> to apps/speed.c and engines/e_aep.c because mingw-w64 comes
> with definitions for "pid_t" and "alarm"

How do we know that these are not or should not be treated as mingw64
bugs? I mean it worked for mingw for years (I wonder how by the way),
now ancestor is *being developed* and how come it's not its fault:-)
Well, I can accept that pid_t could be treated better in OpenSSL (#ifdef
there is nothing but strange), but I don't buy masking of alarm. It's
impossible to implement Unix-ish alarm on Windows and it simply
shouldn't be there (nor SIGALRM definition). Quick check reveals that
alarm is nothing but "return 0." What's more appropriate: to be honest
or not to tell truth? I mean absence of alarm would be honest, while
implementing it as return 0 would be "not telling truth"...

> and in crypto/mem_cmp.c,

http://cvs.openssl.org/chngview?cn=17337. A.

OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to