In the linker options for the win32 build, the generated makefile

$(MKLIB) /out:$(O_CRYPTO) @<<
$(CRYPTOOBJ) advapi32.lib

(and the same for SSLOBJ a few lines further up).

There's a significant problem with having advapi32.lib in there -- it
has nasty side effects if you also link in unicows.lib and try and run
on Windows 98/ME. (unicows.lib is the Microsoft support library that
gives older OSes unicode support as far as possible by linking in
wrappers for the unicode versions of functions that do the "right thing"
on non-unicode OSes).

If you have advapi32.lib linked into libeay32.lib and ssleay32.lib, the
linker winds up exporting various registry functions from advapi32 out
of those libraries, and it turns out to be impossible to use registry
functions and the openssl libraries in an executable with unicows on
Win98/ME, because the resulting executable calls the OpenSSL
(non-magic-unicode) registry functions, rather than the ones from
unicows, so the registry funtions won't work.

The solution is to remove advapi32.lib from the CRYPTOOBJ line at the
bottom of the makefile and put it in the EX_LIBS line at the top -- that
means that all of openssl's own executables still get the required
libraries, but third parties can use openssl without advapi32 problems.
I've spent a few days moving linker order around, and it doesn't seem to
be possible to solve this any other way.

A couple of threads in the past have mentioned that advapi32 was
causing clashes for multiple definitions, and suggested removing it --
what I don't understand is why it's in the linker line for the .lib
rather than in the EX_LIBS line, which would seem to be the best way to
go, and has no problems that I can see. Maybe I'm missing something, of

Anyway, I thought I'd post this to the mailing list so that a solution
is googleable, and in case anyone knows why this is the way it's done.

-- dan
__________________________________________________ ____________________
OpenSSL Project
Development Mailing List
Automated List Manager