view release on metacpan or  search on metacpan

xs/sc_ssl/openssl/source/INSTALL.W32  view on Meta::CPAN

      Note: in the modssl INSTALL.Win32, p: is used rather than c:.


 Troubleshooting
 ---------------

 Since the Win32 build is only occasionally tested it may not always compile
 cleanly.  If you get an error about functions not having numbers assigned
 when you run ms\do_ms then this means the Win32 ordinal files are not up to
 date. You can do:

 > perl util\mkdef.pl crypto ssl update

 then ms\do_XXX should not give a warning any more. However the numbers that
 get assigned by this technique may not match those that eventually get
 assigned in the CVS tree: so anything linked against this version of the
 library may need to be recompiled.

 If you get errors about unresolved symbols there are several possible
 causes.

 If this happens when the DLL is being linked and you have disabled some
 ciphers then it is possible the DEF file generator hasn't removed all
 the disabled symbols: the easiest solution is to edit the DEF files manually
 to delete them. The DEF files are ms\libeay32.def ms\ssleay32.def.

 Another cause is if you missed or ignored the errors about missing numbers
 mentioned above.

 If you get warnings in the code then the compilation will halt.

 The default Makefile for Win32 halts whenever any warnings occur. Since VC++
 has its own ideas about warnings which don't always match up to other
 environments this can happen. The best fix is to edit the file with the
 warning in and fix it. Alternatively you can turn off the halt on warnings by
 editing the CFLAG line in the Makefile and deleting the /WX option.

 You might get compilation errors. Again you will have to fix these or report
 them.

 One final comment about compiling applications linked to the OpenSSL library.
 If you don't use the multithreaded DLL runtime library (/MD option) your
 program will almost certainly crash because malloc gets confused -- the
 OpenSSL DLLs are statically linked to one version, the application must
 not use a different one.  You might be able to work around such problems
 by adding CRYPTO_malloc_init() to your program before any calls to the
 OpenSSL libraries: This tells the OpenSSL libraries to use the same
 malloc(), free() and realloc() as the application.  However there are many
 standard library functions used by OpenSSL that call malloc() internally
 (e.g. fopen()), and OpenSSL cannot change these; so in general you cannot
 rely on CRYPTO_malloc_init() solving your problem, and you should
 consistently use the multithreaded library.

 Linking your application
 ------------------------

 If you link with static OpenSSL libraries [those built with ms/nt.mak],
 then you're expected to additionally link your application with
 WSOCK32.LIB, ADVAPI32.LIB, GDI32.LIB and USER32.LIB. Those developing
 non-interactive service applications might feel concerned about linking
 with latter two, as they are justly associated with interactive desktop,
 which is not available to service processes. The toolkit is designed
 to detect in which context it's currently executed, GUI, console app
 or service, and act accordingly, namely whether or not to actually make
 GUI calls.

 If you link with OpenSSL .DLLs, then you're expected to include into
 your application code small "shim" snippet, which provides glue between
 OpenSSL BIO layer and your compiler run-time. Look up OPENSSL_Applink
 reference page for further details.