X-Git-Url: https://git.openssl.org/gitweb/?a=blobdiff_plain;f=INSTALL;h=b03643fffd1a30401629a27b1fb085d29fc4c6b3;hb=49616d925251a8d38ef2af55d045a778215a7b55;hp=132b2aa1fbae33191b1d120acfe802d2fbbcd6d2;hpb=5b613a15d0d716c714bd7f4902c0676f1498d1f6;p=openssl.git diff --git a/INSTALL b/INSTALL index 132b2aa1fb..b03643fffd 100644 --- a/INSTALL +++ b/INSTALL @@ -18,6 +18,7 @@ For additional platform specific requirements, solutions to specific issues and other details, please read one of these: + * NOTES.UNIX (any supported Unix like system) * NOTES.VMS (OpenVMS) * NOTES.WIN (any supported Windows) * NOTES.DJGPP (DOS platform with DJGPP) @@ -115,6 +116,11 @@ $ @config --prefix=PROGRAM:[INSTALLS] --openssldir=SYS$MANAGER:[OPENSSL] + (Note: if you do add options to the configuration command, please make sure + you've read more than just this Quick Start, such as relevant NOTES.* files, + the options outline below, as configuration options may change the outcome + in otherwise unexpected ways) + Configuration Options --------------------- @@ -379,19 +385,19 @@ Don't build SRTP support no-sse2 - Exclude SSE2 code paths. Normally SSE2 extension is - detected at run-time, but the decision whether or not the - machine code will be executed is taken solely on CPU - capability vector. This means that if you happen to run OS - kernel which does not support SSE2 extension on Intel P4 - processor, then your application might be exposed to - "illegal instruction" exception. There might be a way - to enable support in kernel, e.g. FreeBSD kernel can be - compiled with CPU_ENABLE_SSE, and there is a way to - disengage SSE2 code paths upon application start-up, - but if you aim for wider "audience" running such kernel, - consider no-sse2. Both the 386 and no-asm options imply - no-sse2. + Exclude SSE2 code paths from 32-bit x86 assembly modules. + Normally SSE2 extension is detected at run-time, but the + decision whether or not the machine code will be executed + is taken solely on CPU capability vector. This means that + if you happen to run OS kernel which does not support SSE2 + extension on Intel P4 processor, then your application + might be exposed to "illegal instruction" exception. + There might be a way to enable support in kernel, e.g. + FreeBSD kernel can be compiled with CPU_ENABLE_SSE, and + there is a way to disengage SSE2 code paths upon application + start-up, but if you aim for wider "audience" running + such kernel, consider no-sse2. Both the 386 and + no-asm options imply no-sse2. enable-ssl-trace Build with the SSL Trace capabilities (adds the "-trace" @@ -451,11 +457,12 @@ where loading of shared libraries is supported. 386 - On Intel hardware, use the 80386 instruction set only - (the default x86 code is more efficient, but requires at - least a 486). Note: Use compiler flags for any other CPU - specific configuration, e.g. "-m32" to build x86 code on - an x64 system. + In 32-bit x86 builds, when generating assembly modules, + use the 80386 instruction set only (the default x86 code + is more efficient, but requires at least a 486). Note: + This doesn't affect code generated by compiler, you're + likely to complement configuration command line with + suitable compiler-specific option. no- Don't build support for negotiating the specified SSL/TLS @@ -479,16 +486,25 @@ no- Build without support for the specified algorithm, where is one of: bf, blake2, camellia, cast, chacha, cmac, - des, dh, dsa, ecdh, ecdsa, idea, md4, md5, mdc2, ocb, - ploy1305, rc2, rc4, rmd160, scrypt, seed or whirlpool. The - "ripemd" algorithm is deprecated and if used is synonymous - with rmd160. - - -Dxxx, -lxxx, -Lxxx, -fxxx, -mXXX, -Kxxx - These system specific options will be passed through to the - compiler to allow you to define preprocessor symbols, specify - additional libraries, library directories or other compiler - options. + des, dh, dsa, ecdh, ecdsa, idea, md4, mdc2, ocb, poly1305, + rc2, rc4, rmd160, scrypt, seed or whirlpool. The "ripemd" + algorithm is deprecated and if used is synonymous with rmd160. + + -Dxxx, lxxx, -Lxxx, -Wl, -rpath, -R, -framework, -static + These system specific options will be recocognised and + passed through to the compiler to allow you to define + preprocessor symbols, specify additional libraries, library + directories or other compiler options. It might be worth + noting that some compilers generate code specifically for + processor the compiler currently executes on. This is not + necessarily what you might have in mind, since it might be + unsuitable for execution on other, typically older, + processor. Consult your compiler documentation. + + -xxx, +xxx + Additional options that are not otherwise recognised are + passed through as they are to the compiler as well. Again, + consult your compiler documentation. Installation in Detail @@ -602,17 +618,14 @@ ("openssl"). The libraries will be built in the top-level directory, and the binary will be in the "apps" subdirectory. - If the build fails, look at the output. There may be reasons for - the failure that aren't problems in OpenSSL itself (like missing - standard headers). If you are having problems you can get help by - sending an email to the openssl-users email list (see - https://www.openssl.org/community/mailinglists.html for details). If it - is a bug with OpenSSL itself, please report the problem to - (note that your message will be recorded in the request - tracker publicly readable at - https://www.openssl.org/community/index.html#bugs and will be - forwarded to a public mailing list). Please check out the request - tracker. Maybe the bug was already reported or has already been + If the build fails, look at the output. There may be reasons + for the failure that aren't problems in OpenSSL itself (like + missing standard headers). If you are having problems you can + get help by sending an email to the openssl-users email list (see + https://www.openssl.org/community/mailinglists.html for details). If + it is a bug with OpenSSL itself, please open an issue on GitHub, at + https://github.com/openssl/openssl/issues. Please review the existing + ones first; maybe the bug was already reported or has already been fixed. (If you encounter assembler error messages, try the "no-asm" @@ -900,8 +913,8 @@ supported. If your platform does not provide pthreads or Windows threads then you should Configure with the "no-threads" option. - Note on shared libraries - ------------------------ + Notes on shared libraries + ------------------------- For most systems the OpenSSL Configure script knows what is needed to build shared libraries for libcrypto and libssl. On these systems @@ -910,6 +923,31 @@ where OpenSSL does not know how to build shared libraries the "no-shared" option will be forced and only static libraries will be created. + Shared libraries are named a little differently on different platforms. + One way or another, they all have the major OpenSSL version number as + part of the file name, i.e. for OpenSSL 1.1.x, 1.1 is somehow part of + the name. + + On most POSIXly platforms, shared libraries are named libcrypto.so.1.1 + and libssl.so.1.1. + + on Cygwin, shared libraries are named cygcrypto-1.1.dll and cygssl-1.1.dll + with import libraries libcrypto.dll.a and libssl.dll.a. + + On Windows build with MSVC or using MingW, shared libraries are named + libcrypto-1_1.dll and libssl-1_1.dll for 32-bit Windows, libcrypto-1_1-x64.dll + and libssl-1_1-x64.dll for 64-bit x86_64 Windows, and libcrypto-1_1-ia64.dll + and libssl-1_1-ia64.dll for IA64 Windows. With MSVC, the import libraries + are named libcrypto.lib and libssl.lib, while with MingW, they are named + libcrypto.dll.a and libssl.dll.a. + + On VMS, shareable images (VMS speak for shared libraries) are named + ossl$libcrypto0101_shr.exe and ossl$libssl0101_shr.exe. However, when + OpenSSL is specifically built for 32-bit pointers, the shareable images + are named ossl$libcrypto0101_shr32.exe and ossl$libssl0101_shr32.exe + instead, and when built for 64-bit pointers, they are named + ossl$libcrypto0101_shr64.exe and ossl$libssl0101_shr64.exe. + Note on random number generation --------------------------------