Allow for mingw cross-compile configuration.

[openssl.git] / INSTALL.W32

diff --git a/INSTALL.W32 b/INSTALL.W32
index 0f6c302f0d7fd3566beeba393f824fde3366d87d..868bb23dc9880222f02dc1d814c277e1c0cfd1db 100644 (file)
--- a/INSTALL.W32
+++ b/INSTALL.W32
@@ -3,6 +3,7 @@
  ----------------------------------
 
  [Instructions for building for Windows CE can be found in INSTALL.WCE]
+ [Instructions for building for Win64 can be found in INSTALL.W64]
 
  Heres a few comments about building OpenSSL in Windows environments.  Most
  of this is tested on Win32 but it may also work in Win 3.1 with some
@@ -28,35 +29,20 @@
  If you want to compile in the assembly language routines with Visual C++ then
  you will need an assembler. This is worth doing because it will result in
  faster code: for example it will typically result in a 2 times speedup in the
- RSA routines. Currently the following assemblers are supported:
-
-  * Microsoft MASM (aka "ml")
-  * Free Netwide Assembler NASM.
-
- MASM is distributed with most versions of VC++. For the versions where it is
- not included in VC++, it is also distributed with some Microsoft DDKs, for
- example the Windows NT 4.0 DDK and the Windows 98 DDK. If you do not have
- either of these DDKs then you can just download the binaries for the Windows
- 98 DDK and extract and rename the two files XXXXXml.exe and XXXXXml.err, to
- ml.exe and ml.err and install somewhere on your PATH. Both DDKs can be
- downloaded from the Microsoft developers site www.msdn.com.
-
- NASM is freely available. Version 0.98 was used during testing: other versions
- may also work. It is available from many places, see for example:
- http://www.kernel.org/pub/software/devel/nasm/binaries/win32/
- The NASM binary nasmw.exe needs to be installed anywhere on your PATH.
+ RSA routines. Assembler choice is limited to Free Netwise Assember, NASM,
+ available for download from http://sourceforge.net/projects/nasm/, even in
+ binary form. The NASM binary, nasmw.exe needs to be installed anywhere on
+ your %PATH%.
 
  Firstly you should run Configure:
 
- > perl Configure VC-WIN32
+ > perl Configure VC-WIN32 --prefix=c:/some/openssl/dir
+
+Where the prefix argument specifies where OpenSSL will be installed to.
 
  Next you need to build the Makefiles and optionally the assembly language
  files:
 
- - If you are using MASM then run:
-
-   > ms\do_masm
-
  - If you are using NASM then run:
 
    > ms\do_nasm
@@ -76,8 +62,12 @@
  If all is well it should compile and you will have some DLLs and executables
  in out32dll. If you want to try the tests then do:
  
- > cd out32dll
- > ..\ms\test
+ > nmake -f ms\ntdll.mak test
+
+
+To install OpenSSL to the specified location do:
+
+> nmake -f ms\ntdll.mak install
 
  Tweaks:
 
@@ -87,6 +77,12 @@
  compiled in. Note that mk1mf.pl expects the platform to be the last argument
  on the command line, so 'debug' must appear before that, as all other options.
 
+
+ By default in 0.9.8 OpenSSL will compile builtin ENGINES into the libeay32.dll
+ shared library. If you specify the "no-static-engine" option on the command
+ line to Configure the shared library build (ms\ntdll.mak) will compile the
+ engines as separate DLLs.
+
  The default Win32 environment is to leave out any Windows NT specific
  features.
 
@@ -97,6 +93,8 @@
  You can also build a static version of the library using the Makefile
  ms\nt.mak
 
+
+
  Borland C++ builder 5
  ---------------------
 
@@ -286,3 +284,21 @@
  (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.