I don't believe the specific compilation problems described are a current
issue. dtls1.h does still include winsock.h as previously discussed on
openssl-dev (re ticket 2187). This has been removed from the forthcoming
OpenSSL 1.1.0. Closing this ticket.
Matt
Roumen Petrov via RT wrote:
M.-A. Lemburg via RT wrote:
An application that only includes openssl/ssl.h from OpenSSL
1.0.0 and doesn't use winsock.h will run into problems on Windows,
since the dtls1.h header file includes the winsock.h header file long
after the ossl_typ.h header file was
Roumen Petrov via RT wrote:
M.-A. Lemburg via RT wrote:
An application that only includes openssl/ssl.h from OpenSSL
1.0.0 and doesn't use winsock.h will run into problems on Windows,
since the dtls1.h header file includes the winsock.h header file long
after the ossl_typ.h header file was
An application that only includes openssl/ssl.h from OpenSSL
1.0.0 and doesn't use winsock.h will run into problems on Windows,
since the dtls1.h header file includes the winsock.h header file long
after the ossl_typ.h header file was loaded.
The latter includes a couple of #undefs needed to work
M.-A. Lemburg via RT wrote:
An application that only includes openssl/ssl.h from OpenSSL
1.0.0 and doesn't use winsock.h will run into problems on Windows,
since the dtls1.h header file includes the winsock.h header file long
after the ossl_typ.h header file was loaded.
What about to define
M.-A. Lemburg via RT wrote:
An application that only includes openssl/ssl.h from OpenSSL
1.0.0 and doesn't use winsock.h will run into problems on Windows,
since the dtls1.h header file includes the winsock.h header file long
after the ossl_typ.h header file was loaded.
What about to define
