openssl
/
openssl
mirror of https://github.com/openssl/openssl
1
0
Fork 0
Code Issues Releases Wiki Activity

INSTALL: clarify 386 and no-sse2 options. 

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
This commit is contained in:
Andy Polyakov 2016-11-20 21:52:41 +01:00
parent 76f572ed04
commit 5ae5dc9661
2 changed files with 28 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
Configure
View File

@ -60,11 +60,12 @@ my $usage="Usage: Configure [no-<cipher> ...] [enable-<cipher> ...] [-Dxxx] [-lx
# zlib-dynamic Like "zlib", but the zlib library is expected to be a shared
# library and will be loaded in run-time by the OpenSSL library.
# sctp include SCTP support
# 386 generate 80386 code
# enable-weak-ssl-ciphers
# Enable weak ciphers that are disabled by default. This currently
# only includes RC4 based ciphers.
# no-sse2 disables IA-32 SSE2 code, above option implies no-sse2
# 386 generate 80386 code in assembly modules
# no-sse2 disables IA-32 SSE2 code in assembly modules, the above
# mentioned '386' option implies this one
# no-<cipher> build without specified algorithm (rsa, idea, rc5, ...)
# -<xxx> +<xxx> compiler options are passed through
# -static while -static is also a pass-through compiler option (and

44
INSTALL
View File

@ -383,19 +383,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"
@ -458,11 +458,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.
enable-tls1_3
TODO(TLS1.3): Make this enabled by default
@ -500,7 +501,12 @@
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.
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.
Installation in Detail