Hi Daniel,

> > SSL_LIBS = libeay32.lib ssleay32.lib gdi32.lib user32.lib advapi32.lib
> >
> > ..to satisfy some questionable dependencies in the fatal error
> > handling in openssl 1.0.0e when linking curl.exe.
>
> So openssl 1.0.0e suddenly requires _three_ more libs to be used?
>
> I'd appreciate a comment or two from someone actually using Windows about
this suggested change and its impact.

Here's my input... but maybe someone with makefile experience will know
more:

I believe the problem arises because the mingw and makefile builds don't
link with any of the Windows default libraries like Visual Studio projects
do. Anyone who is using the supplied vc6 project files or their own vc7,
vc8, vc9 and vc10 project files (like I do) won't see the problem because
the command line for a Visual Studio build includes: "kernel32.lib"
"user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib"
"shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib"
"odbccp32.lib"

I've just recently upgraded OpenSSL from v0.9.8r to v1.0.0e myself and would
have to download the older versions again to double check the source but in
v1.0.0e cryptlib.c, for example, uses GetUserObjectInformationW() and
GetProcessWindowStation() so yes Curl.exe does need to link against these
libraries. Alternatively you could add them to the WIN_LIBS (If I've
understood the makefile properly) but as they are a dependency of OpenSSL
you may as well have it in SSL_LIBS.

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-12-07