mirror of
https://github.com/openssl/openssl.git
synced 2024-11-27 05:21:51 +08:00
7a77bd9de7
The windows installation instructions were very out of date. Substantial update to the text. Remove a lot of historical stuff that isn't relevant any more, and merge the win64 and win32 instructions into one file. Reviewed-by: Richard Levitte <levitte@openssl.org>
191 lines
6.1 KiB
Plaintext
191 lines
6.1 KiB
Plaintext
|
|
INSTALLATION ON WINDOWS PLATFORMS
|
|
---------------------------------
|
|
|
|
[Instructions for building for Windows CE can be found in INSTALL.WCE]
|
|
|
|
Here are a few comments about building OpenSSL for Windows environments.
|
|
|
|
- you need Perl. Unless you will build on Cygwin, you will
|
|
need ActiveState Perl, available from http://www.activestate.com/ActivePerl.
|
|
|
|
- one of the following C compilers:
|
|
|
|
* Visual C++
|
|
* GNU C (Cygwin or MinGW)
|
|
|
|
- Netwide Assembler, a.k.a. NASM, available from http://www.nasm.us,
|
|
is required if you intend to utilize assembler modules. Note that NASM
|
|
is now the only supported assembler. Without this the "Configure" step below
|
|
must be done with the "no-asm" option. The Microsoft provided assembler is NOT
|
|
supported.
|
|
|
|
Visual C++
|
|
----------
|
|
|
|
If you want to compile in the assembly language routines with Visual
|
|
C++, then you will need the Netwide Assembler binary, nasmw.exe or nasm.exe, to
|
|
be available on your %PATH%.
|
|
|
|
Firstly you should run Configure and generate the Makefiles. If you don't want
|
|
the assembly language files then add the "no-asm" option (without quotes) to
|
|
the Configure lines below.
|
|
|
|
For Win32:
|
|
|
|
> perl Configure VC-WIN32 --prefix=c:\some\openssl\dir
|
|
> ms\do_nasm
|
|
|
|
Note: replace the last line above with the following if not using the assembly
|
|
language files:
|
|
|
|
> ms\do_ms
|
|
|
|
For Win64/x64:
|
|
|
|
> perl Configure VC-WIN64A --prefix=c:\some\openssl\dir
|
|
> ms\do_win64a
|
|
|
|
For Win64/IA64:
|
|
|
|
> perl Configure VC-WIN64I --prefix=c:\some\openssl\dir
|
|
> ms\do_win64i
|
|
|
|
Where the prefix argument specifies where OpenSSL will be installed to.
|
|
|
|
Then from the VC++ environment at a prompt do the following. Note, your %PATH%
|
|
and other environment variables should be set up for 32-bit or 64-bit
|
|
development as appropriate.
|
|
|
|
> nmake -f ms\ntdll.mak
|
|
|
|
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:
|
|
|
|
> nmake -f ms\ntdll.mak test
|
|
|
|
To install OpenSSL to the specified location do:
|
|
|
|
> nmake -f ms\ntdll.mak install
|
|
|
|
Tweaks:
|
|
|
|
There are various changes you can make to the Windows compile
|
|
environment. By default the library is not compiled with debugging
|
|
symbols. If you add --debug to the Configure lines above then debugging symbols
|
|
will be compiled in.
|
|
|
|
By default in 1.1.0 OpenSSL will compile builtin ENGINES into separate shared
|
|
libraries. If you specify the "enable-static-engine" option on the command line
|
|
to Configure the shared library build (ms\ntdll.mak) will compile the engines
|
|
into libeay32.dll instead.
|
|
|
|
You can also build a static version of the library using the Makefile
|
|
ms\nt.mak
|
|
|
|
GNU C (Cygwin)
|
|
--------------
|
|
|
|
Cygwin implements a Posix/Unix runtime system (cygwin1.dll) on top of the
|
|
Windows subsystem and provides a bash shell and GNU tools environment.
|
|
Consequently, a make of OpenSSL with Cygwin is virtually identical to the
|
|
Unix procedure. It is also possible to create Windows binaries that only
|
|
use the Microsoft C runtime system (msvcrt.dll or crtdll.dll) using
|
|
MinGW. MinGW can be used in the Cygwin development environment or in a
|
|
standalone setup as described in the following section.
|
|
|
|
To build OpenSSL using Cygwin:
|
|
|
|
* Install Cygwin (see http://cygwin.com/)
|
|
|
|
* Install Perl and ensure it is in the path. Both Cygwin perl
|
|
(5.6.1-2 or newer) and ActivePerl work.
|
|
|
|
* Run the Cygwin bash shell
|
|
|
|
* $ tar zxvf openssl-x.x.x.tar.gz
|
|
$ cd openssl-x.x.x
|
|
|
|
To build the Cygwin version of OpenSSL:
|
|
|
|
$ ./config
|
|
[...]
|
|
$ make
|
|
[...]
|
|
$ make test
|
|
$ make install
|
|
|
|
This will create a default install in /usr/local/ssl.
|
|
|
|
To build the MinGW version (native Windows) in Cygwin:
|
|
|
|
$ ./Configure mingw
|
|
[...]
|
|
$ make
|
|
[...]
|
|
$ make test
|
|
$ make install
|
|
|
|
Cygwin Notes:
|
|
|
|
"make test" and normal file operations may fail in directories
|
|
mounted as text (i.e. mount -t c:\somewhere /home) due to Cygwin
|
|
stripping of carriage returns. To avoid this ensure that a binary
|
|
mount is used, e.g. mount -b c:\somewhere /home.
|
|
|
|
GNU C (MinGW/MSYS)
|
|
-------------
|
|
|
|
* Compiler and shell environment installation:
|
|
|
|
MinGW and MSYS are available from http://www.mingw.org/, both are
|
|
required. Run the installers and do whatever magic they say it takes
|
|
to start MSYS bash shell with GNU tools on its PATH.
|
|
|
|
* Compile OpenSSL:
|
|
|
|
$ ./config
|
|
[...]
|
|
$ make
|
|
[...]
|
|
$ make test
|
|
|
|
This will create the library and binaries in root source directory
|
|
and openssl.exe application in apps directory.
|
|
|
|
It is also possible to cross-compile it on Linux by configuring
|
|
with './Configure --cross-compile-prefix=i386-mingw32- mingw ...'. Other
|
|
possible targets include x86_64-w64-mingw32- and i686-w64-mingw32-.
|
|
|
|
libcrypto.a and libssl.a are the static libraries. To use the DLLs,
|
|
link with libeay32.a and libssl32.a instead.
|
|
|
|
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
|
|
WS2_32.LIB, ADVAPI32.LIB, GDI32.LIB and USER32.LIB. Those developing
|
|
non-interactive service applications might feel concerned about linking
|
|
with the 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. Additionally those who wish to
|
|
/DELAYLOAD:GDI32.DLL and /DELAYLOAD:USER32.DLL and actually keep them
|
|
off service process should consider implementing and exporting from
|
|
.exe image in question own _OPENSSL_isservice not relying on USER32.DLL.
|
|
E.g., on Windows Vista and later you could:
|
|
|
|
__declspec(dllexport) __cdecl BOOL _OPENSSL_isservice(void)
|
|
{ DWORD sess;
|
|
if (ProcessIdToSessionId(GetCurrentProcessId(),&sess))
|
|
return sess==0;
|
|
return FALSE;
|
|
}
|
|
|
|
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. See the OPENSSL_Applink
|
|
manual page for further details.
|