mirror of
https://github.com/openssl/openssl.git
synced 2024-12-21 06:09:35 +08:00
140 lines
5.2 KiB
Plaintext
140 lines
5.2 KiB
Plaintext
|
|
NOTES FOR THE WINDOWS PLATFORMS
|
|
===============================
|
|
|
|
Requirement details for native (Visual C++) builds
|
|
--------------------------------------------------
|
|
|
|
In addition to the requirements and instructions listed in INSTALL,
|
|
this are required as well:
|
|
|
|
- You need Perl. We recommend ActiveState Perl, available from
|
|
https://www.activestate.com/ActivePerl. Another viable alternative
|
|
appears to be Strawberry Perl, http://strawberryperl.com.
|
|
You also need the perl module Text::Template, available on CPAN.
|
|
Please read NOTES.PERL for more information.
|
|
|
|
- You need a C compiler. OpenSSL has been tested to build with these:
|
|
|
|
* Visual C++
|
|
|
|
- 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 the only supported assembler. The Microsoft provided assembler is NOT
|
|
supported.
|
|
|
|
|
|
Visual C++ (native Windows)
|
|
---------------------------
|
|
|
|
Installation directories
|
|
|
|
The default installation directories are derived from environment
|
|
variables.
|
|
|
|
For VC-WIN32, the following defaults are use:
|
|
|
|
PREFIX: %ProgramFiles(86)%\OpenSSL
|
|
OPENSSLDIR: %CommonProgramFiles(86)%\SSL
|
|
|
|
For VC-WIN64, the following defaults are use:
|
|
|
|
PREFIX: %ProgramW6432%\OpenSSL
|
|
OPENSSLDIR: %CommonProgramW6432%\SSL
|
|
|
|
Should those environment variables not exist (on a pure Win32
|
|
installation for examples), these fallbacks are used:
|
|
|
|
PREFIX: %ProgramFiles%\OpenSSL
|
|
OPENSSLDIR: %CommonProgramFiles%\SSL
|
|
|
|
ALSO NOTE that those directories are usually write protected, even if
|
|
your account is in the Administrators group. To work around that,
|
|
start the command prompt by right-clicking on it and choosing "Run as
|
|
Administrator" before running 'nmake install'. The other solution
|
|
is, of course, to choose a different set of directories by using
|
|
--prefix and --openssldir when configuring.
|
|
|
|
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.
|
|
|
|
To build OpenSSL using Cygwin, you need to:
|
|
|
|
* Install Cygwin (see https://cygwin.com/)
|
|
|
|
* Install Cygwin Perl and ensure it is in the path. Recall that
|
|
as least 5.10.0 is required.
|
|
|
|
* Run the Cygwin bash shell
|
|
|
|
Apart from that, follow the Unix instructions in INSTALL.
|
|
|
|
NOTE: "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.
|
|
|
|
It is also possible to create "conventional" Windows binaries that use
|
|
the Microsoft C runtime system (msvcrt.dll or crtdll.dll) using MinGW
|
|
development add-on for Cygwin. MinGW is supported even as a standalone
|
|
setup as described in the following section. In the context you should
|
|
recognize that binaries targeting Cygwin itself are not interchangeable
|
|
with "conventional" Windows binaries you generate with/for MinGW.
|
|
|
|
|
|
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 and matching Perl on its PATH.
|
|
"Matching Perl" refers to chosen "shell environment", i.e. if built
|
|
under MSYS, then Perl compiled for MSYS must be used.
|
|
|
|
Alternatively, one can use MSYS2 from https://msys2.github.io/,
|
|
which includes MingW (32-bit and 64-bit).
|
|
|
|
* It is also possible to cross-compile it on Linux by configuring
|
|
with './Configure --cross-compile-prefix=i386-mingw32- mingw ...'.
|
|
Other possible cross compile prefixes include x86_64-w64-mingw32-
|
|
and i686-w64-mingw32-.
|
|
|
|
|
|
Linking your application
|
|
------------------------
|
|
|
|
This section applies to non-Cygwin builds.
|
|
|
|
If you link with static OpenSSL libraries then you're expected to
|
|
additionally link your application with WS2_32.LIB, GDI32.LIB,
|
|
ADVAPI32.LIB, CRYPT32.LIB and USER32.LIB. Those developing
|
|
non-interactive service applications might feel concerned about
|
|
linking with GDI32.LIB and USER32.LIB, 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.
|