+++ /dev/null
-
- 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
- http://www.activestate.com/ActivePerl.
- 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-WIN32, 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
-
-
- 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 http://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 is highly recommended.
-
- Alternativelly, one can use MSYS2 from http://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.
projects / openssl.git / blobdiff