2015-11-24 05:44:58 +00:00
|
|
|
## -*- mode: perl; -*-
|
2015-02-24 22:40:22 +00:00
|
|
|
## Standard openssl configuration targets.
|
|
|
|
|
2016-03-02 18:13:26 +00:00
|
|
|
sub picker {
|
|
|
|
my %opts = @_;
|
|
|
|
return sub { add($opts{default} || (),
|
|
|
|
$opts{$config{build_type}} || ())->(); }
|
|
|
|
}
|
|
|
|
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
sub threads {
|
|
|
|
my @flags = @_;
|
|
|
|
return sub { add($disabled{threads} ? () : @flags)->(); }
|
|
|
|
}
|
|
|
|
|
|
|
|
sub combine {
|
|
|
|
my @stuff = @_;
|
|
|
|
return sub { add(@stuff)->(); }
|
|
|
|
}
|
|
|
|
|
2015-02-24 22:40:22 +00:00
|
|
|
%targets = (
|
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### Basic configs that should work on any 32-bit box
|
2015-03-10 23:58:50 +00:00
|
|
|
"gcc" => {
|
|
|
|
cc => "gcc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => picker(debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
|
|
|
},
|
|
|
|
"cc" => {
|
|
|
|
cc => "cc",
|
|
|
|
cflags => "-O",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### VOS Configurations
|
2015-03-10 23:58:50 +00:00
|
|
|
"vos-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => picker(default => "-Wall -DOPENSSL_SYS_VOS -D_POSIX_C_SOURCE=200112L -D_BSD -D_VOS_EXTENDED_NAMES -DB_ENDIAN",
|
|
|
|
debug => "-O0 -g -DBN_DEBUG -DREF_DEBUG -DCONF_DEBUG",
|
|
|
|
release => "-O3"),
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "VOS",
|
|
|
|
lflags => "-Wl,-map",
|
|
|
|
bn_ops => "BN_LLONG",
|
|
|
|
shared_extension => ".so",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2016-02-17 23:32:13 +00:00
|
|
|
#### Solaris configurations
|
2015-11-23 13:12:17 +00:00
|
|
|
"solaris-common" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-11-23 13:12:17 +00:00
|
|
|
template => 1,
|
|
|
|
cflags => "-DFILIO_H",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lresolv -lsocket -lnsl -ldl"),
|
2015-11-23 13:12:17 +00:00
|
|
|
dso_scheme => "dlfcn",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-11-23 13:12:17 +00:00
|
|
|
shared_target => "solaris-shared",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
#### Solaris x86 with GNU C setups
|
2015-03-10 23:58:50 +00:00
|
|
|
"solaris-x86-gcc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
# -DOPENSSL_NO_INLINE_ASM switches off inline assembler. We have
|
|
|
|
# to do it here because whenever GNU C instantiates an assembler
|
|
|
|
# template it surrounds it with #APP #NO_APP comment pair which
|
|
|
|
# (at least Solaris 7_x86) /usr/ccs/bin/as fails to assemble
|
|
|
|
# with "Illegal mnemonic" error message.
|
2015-11-23 13:12:17 +00:00
|
|
|
inherit_from => [ "solaris-common", asm("x86_elf_asm") ],
|
2015-03-16 21:33:36 +00:00
|
|
|
cc => "gcc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add_before(picker(default => "-Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM",
|
|
|
|
debug => "-O0 -g",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
release => "-O3 -fomit-frame-pointer"),
|
|
|
|
threads("-pthread")),
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_ldflag => "-shared",
|
|
|
|
},
|
|
|
|
"solaris64-x86_64-gcc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
# -shared -static-libgcc might appear controversial, but modules
|
|
|
|
# taken from static libgcc do not have relocations and linking
|
|
|
|
# them into our shared objects doesn't have any negative side
|
|
|
|
# effects. On the contrary, doing so makes it possible to use
|
|
|
|
# gcc shared build with Sun C. Given that gcc generates faster
|
|
|
|
# code [thanks to inline assembler], I would actually recommend
|
|
|
|
# to consider using gcc shared build even with vendor compiler:-)
|
|
|
|
# <appro@fy.chalmers.se>
|
2015-11-23 13:12:17 +00:00
|
|
|
inherit_from => [ "solaris-common", asm("x86_64_asm") ],
|
2015-03-16 21:33:36 +00:00
|
|
|
cc => "gcc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add_before(picker(default => "-m64 -Wall -DL_ENDIAN",
|
|
|
|
debug => "-O0 -g",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
release => "-O3"),
|
|
|
|
threads("-pthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "elf",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_ldflag => "-m64 -shared -static-libgcc",
|
|
|
|
multilib => "/64",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
#### Solaris x86 with Sun C setups
|
2015-03-10 23:58:50 +00:00
|
|
|
"solaris-x86-cc" => {
|
2015-11-23 13:12:17 +00:00
|
|
|
inherit_from => [ "solaris-common" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add_before(picker(default => "-xarch=generic -xstrconst -Xa -DL_ENDIAN",
|
|
|
|
debug => "-g",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
release => "-xO5 -xregs=frameptr -xdepend -xbuiltin"),
|
|
|
|
threads("-D_REENTRANT")),
|
|
|
|
lflags => add(threads("-mt")),
|
|
|
|
ex_libs => add(threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_cflag => "-KPIC",
|
|
|
|
shared_ldflag => "-G -dy -z text",
|
|
|
|
},
|
|
|
|
"solaris64-x86_64-cc" => {
|
2015-11-23 13:12:17 +00:00
|
|
|
inherit_from => [ "solaris-common", asm("x86_64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add_before(picker(default => "-xarch=generic64 -xstrconst -Xa -DL_ENDIAN",
|
|
|
|
debug => "-g",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
release => "-xO5 -xdepend -xbuiltin"),
|
|
|
|
threads("-D_REENTRANT")),
|
|
|
|
thread_scheme => "pthreads",
|
|
|
|
lflags => add(threads("-mt")),
|
|
|
|
ex_libs => add(threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "elf",
|
|
|
|
shared_cflag => "-KPIC",
|
2015-03-16 21:33:36 +00:00
|
|
|
shared_ldflag => "-xarch=generic64 -G -dy -z text",
|
2015-03-10 23:58:50 +00:00
|
|
|
multilib => "/64",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
#### SPARC Solaris with GNU C setups
|
2015-03-10 23:58:50 +00:00
|
|
|
"solaris-sparcv7-gcc" => {
|
2015-11-23 13:12:17 +00:00
|
|
|
inherit_from => [ "solaris-common" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add_before(picker(default => "-Wall -DB_ENDIAN -DBN_DIV2W",
|
|
|
|
debug => "-O0 -g",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
release => "-O3"),
|
|
|
|
threads("-pthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_ldflag => "-shared",
|
|
|
|
},
|
|
|
|
"solaris-sparcv8-gcc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "solaris-sparcv7-gcc", asm("sparcv8_asm") ],
|
2016-02-24 23:17:59 +00:00
|
|
|
cflags => add_before("-mcpu=v8"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"solaris-sparcv9-gcc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
# -m32 should be safe to add as long as driver recognizes
|
2015-11-23 13:12:17 +00:00
|
|
|
# -mcpu=ultrasparc
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "solaris-sparcv7-gcc", asm("sparcv9_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add_before(picker(default => "-m32 -mcpu=ultrasparc",
|
|
|
|
debug => "-DBN_DEBUG -DREF_DEBUG -DCONF_DEBUG -DBN_CTX_DEBUG -DPEDANTIC -O -g -pedantic -ansi -Wshadow -Wno-long-long -D__EXTENSIONS__")),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"solaris64-sparcv9-gcc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "solaris-sparcv9-gcc" ],
|
2015-11-23 13:12:17 +00:00
|
|
|
cflags => sub { my $f=join(" ",@_); $f =~ s/\-m32/-m64/; $f; },
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_ldflag => "-m64 -shared",
|
|
|
|
multilib => "/64",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
#### SPARC Solaris with Sun C setups
|
|
|
|
# SC4.0 doesn't pass 'make test', upgrade to SC5.0 or SC4.2.
|
|
|
|
# SC4.2 is ok, better than gcc even on bn as long as you tell it -xarch=v8
|
|
|
|
# SC5.0 note: Compiler common patch 107357-01 or later is required!
|
2015-03-10 23:58:50 +00:00
|
|
|
"solaris-sparcv7-cc" => {
|
2015-11-23 13:12:17 +00:00
|
|
|
inherit_from => [ "solaris-common" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add_before(picker(default => "-xstrconst -Xa -DB_ENDIAN -DBN_DIV2W",
|
|
|
|
debug => "-g -DBN_DEBUG -DREF_DEBUG -DCONF_DEBUG -DBN_CTX_DEBUG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
release => "-xO5 -xdepend"),
|
|
|
|
threads("-D_REENTRANT")),
|
|
|
|
lflags => add(threads("-mt")),
|
|
|
|
ex_libs => add(threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_cflag => "-KPIC",
|
|
|
|
shared_ldflag => "-G -dy -z text",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
####
|
2015-03-10 23:58:50 +00:00
|
|
|
"solaris-sparcv8-cc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "solaris-sparcv7-cc", asm("sparcv8_asm") ],
|
2016-02-24 23:17:59 +00:00
|
|
|
cflags => add_before("-xarch=v8"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"solaris-sparcv9-cc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "solaris-sparcv7-cc", asm("sparcv9_asm") ],
|
2016-02-24 23:17:59 +00:00
|
|
|
cflags => add_before("-xarch=v8plus -xtarget=ultra"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"solaris64-sparcv9-cc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "solaris-sparcv7-cc", asm("sparcv9_asm") ],
|
2016-02-24 23:17:59 +00:00
|
|
|
cflags => add_before("-xarch=v9 -xtarget=ultra"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_ldflag => "-xarch=v9 -G -dy -z text",
|
|
|
|
multilib => "/64",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
#### IRIX 5.x configs
|
|
|
|
# -mips2 flag is added by ./config when appropriate.
|
2015-03-10 23:58:50 +00:00
|
|
|
"irix-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("mips32_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => picker(default => "-DB_ENDIAN",
|
|
|
|
debug => "-g -O0",
|
|
|
|
release => "-O3"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "o32",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "irix-shared",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
|
|
|
"irix-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("mips32_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => picker(default => "-use_readonly_const -DB_ENDIAN",
|
|
|
|
debug => "-g -O0",
|
|
|
|
release => "-O2"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "o32",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "irix-shared",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
#### IRIX 6.x configs
|
|
|
|
# Only N32 and N64 ABIs are supported. If you need O32 ABI build, invoke
|
|
|
|
# './Configure irix-cc -o32' manually.
|
2015-03-10 23:58:50 +00:00
|
|
|
"irix-mips3-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("mips64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-mabi=n32 -DB_ENDIAN -DBN_DIV3W",
|
|
|
|
debug => "-g -O0",
|
|
|
|
release => "-O3"),
|
|
|
|
threads("-D_SGI_MP_SOURCE -pthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "RC4_CHAR SIXTY_FOUR_BIT",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "n32",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "irix-shared",
|
|
|
|
shared_ldflag => "-mabi=n32",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
multilib => "32",
|
|
|
|
},
|
|
|
|
"irix-mips3-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("mips64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-n32 -mips3 -use_readonly_const -G0 -rdata_shared -DB_ENDIAN -DBN_DIV3W",
|
|
|
|
debug => "-g -O0",
|
|
|
|
release => "-O2"),
|
|
|
|
threads("-D_SGI_MP_SOURCE")),
|
|
|
|
ex_libs => add(threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "RC4_CHAR SIXTY_FOUR_BIT",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "n32",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "irix-shared",
|
|
|
|
shared_ldflag => "-n32",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
multilib => "32",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
# N64 ABI builds.
|
2015-03-10 23:58:50 +00:00
|
|
|
"irix64-mips4-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("mips64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-mabi=64 -mips4 -DB_ENDIAN -DBN_DIV3W",
|
|
|
|
debug => "-g -O0",
|
|
|
|
release => "-O3"),
|
|
|
|
threads("-D_SGI_MP_SOURCE")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "RC4_CHAR SIXTY_FOUR_BIT_LONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "64",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "irix-shared",
|
|
|
|
shared_ldflag => "-mabi=64",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
multilib => "64",
|
|
|
|
},
|
|
|
|
"irix64-mips4-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("mips64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-64 -mips4 -use_readonly_const -G0 -rdata_shared -DB_ENDIAN -DBN_DIV3W",
|
|
|
|
debug => "-g -O0",
|
|
|
|
release => "-O2"),
|
|
|
|
threads("-D_SGI_MP_SOURCE")),
|
|
|
|
ex_libs => add(threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "RC4_CHAR SIXTY_FOUR_BIT_LONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "64",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "irix-shared",
|
|
|
|
shared_ldflag => "-64",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
multilib => "64",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
#### Unified HP-UX ANSI C configs.
|
|
|
|
# Special notes:
|
|
|
|
# - Originally we were optimizing at +O4 level. It should be noted
|
|
|
|
# that the only difference between +O3 and +O4 is global inter-
|
|
|
|
# procedural analysis. As it has to be performed during the link
|
|
|
|
# stage the compiler leaves behind certain pseudo-code in lib*.a
|
|
|
|
# which might be release or even patch level specific. Generating
|
|
|
|
# the machine code for and analyzing the *whole* program appears
|
|
|
|
# to be *extremely* memory demanding while the performance gain is
|
|
|
|
# actually questionable. The situation is intensified by the default
|
|
|
|
# HP-UX data set size limit (infamous 'maxdsiz' tunable) of 64MB
|
|
|
|
# which is way too low for +O4. In other words, doesn't +O3 make
|
|
|
|
# more sense?
|
|
|
|
# - Keep in mind that the HP compiler by default generates code
|
|
|
|
# suitable for execution on the host you're currently compiling at.
|
2016-02-26 19:30:15 +00:00
|
|
|
# If the toolkit is meant to be used on various PA-RISC processors
|
2015-03-16 21:33:36 +00:00
|
|
|
# consider './Configure hpux-parisc-[g]cc +DAportable'.
|
2015-02-24 22:40:22 +00:00
|
|
|
# - -DMD32_XARRAY triggers workaround for compiler bug we ran into in
|
|
|
|
# 32-bit message digests. (For the moment of this writing) HP C
|
|
|
|
# doesn't seem to "digest" too many local variables (they make "him"
|
|
|
|
# chew forever:-). For more details look-up MD32_XARRAY comment in
|
|
|
|
# crypto/sha/sha_lcl.h.
|
2015-03-16 21:33:36 +00:00
|
|
|
# - originally there were 32-bit hpux-parisc2-* targets. They were
|
2016-02-26 19:30:15 +00:00
|
|
|
# scrapped, because a) they were not interchangeable with other 32-bit
|
2015-03-16 21:33:36 +00:00
|
|
|
# targets; a) when critical 32-bit assembly modules detect if they
|
|
|
|
# are executed on PA-RISC 2.0 and thus adequate performance is
|
|
|
|
# provided.
|
2015-02-24 22:40:22 +00:00
|
|
|
# <appro@fy.chalmers.se>
|
2015-03-10 23:58:50 +00:00
|
|
|
"hpux-parisc-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-DB_ENDIAN -DBN_DIV2W",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
|
|
|
threads("-pthread")),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-Wl,+s -ldld"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dl",
|
|
|
|
shared_target => "hpux-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_ldflag => "-shared",
|
|
|
|
shared_extension => ".sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
|
|
|
"hpux-parisc1_1-gcc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "hpux-parisc-gcc", asm("parisc11_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
multilib => "/pa1.1",
|
|
|
|
},
|
|
|
|
"hpux64-parisc2-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("parisc20_64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-DB_ENDIAN",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
|
|
|
threads("-D_REENTRANT")),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-ldl"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "hpux-shared",
|
|
|
|
shared_cflag => "-fpic",
|
|
|
|
shared_ldflag => "-shared",
|
|
|
|
shared_extension => ".sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
multilib => "/pa20_64",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
# More attempts at unified 10.X and 11.X targets for HP C compiler.
|
|
|
|
#
|
|
|
|
# Chris Ruemmler <ruemmler@cup.hp.com>
|
|
|
|
# Kevin Steves <ks@hp.se>
|
2015-03-10 23:58:50 +00:00
|
|
|
"hpux-parisc-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "+Optrs_strongly_typed -Ae +ESlit -DB_ENDIAN -DBN_DIV2W -DMD32_XARRAY",
|
|
|
|
debug => "+O0 +d -g",
|
|
|
|
release => "+O3"),
|
|
|
|
threads("-D_REENTRANT")),
|
|
|
|
ex_libs => add("-Wl,+s -ldld",threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dl",
|
|
|
|
shared_target => "hpux-shared",
|
|
|
|
shared_cflag => "+Z",
|
|
|
|
shared_ldflag => "-b",
|
|
|
|
shared_extension => ".sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
|
|
|
"hpux-parisc1_1-cc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "hpux-parisc-cc", asm("parisc11_asm") ],
|
2016-02-24 23:17:59 +00:00
|
|
|
cflags => add_before("+DA1.1"),
|
2015-03-10 23:58:50 +00:00
|
|
|
multilib => "/pa1.1",
|
|
|
|
},
|
|
|
|
"hpux64-parisc2-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("parisc20_64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "+DD64 +Optrs_strongly_typed -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY",
|
|
|
|
debug => "+O0 +d -g",
|
|
|
|
release => "+O3"),
|
|
|
|
threads("-D_REENTRANT")),
|
|
|
|
ex_libs => add("-ldl",threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "hpux-shared",
|
|
|
|
shared_cflag => "+Z",
|
|
|
|
shared_ldflag => "+DD64 -b",
|
|
|
|
shared_extension => ".sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
multilib => "/pa20_64",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
# HP/UX IA-64 targets
|
2015-03-10 23:58:50 +00:00
|
|
|
"hpux-ia64-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("ia64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-Ae +DD32 +Olit=all -z -DB_ENDIAN",
|
|
|
|
debug => "+O0 +d -g",
|
|
|
|
release => "+O2"),
|
|
|
|
threads("-D_REENTRANT")),
|
|
|
|
ex_libs => add("-ldl",threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "hpux-shared",
|
|
|
|
shared_cflag => "+Z",
|
|
|
|
shared_ldflag => "+DD32 -b",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
multilib => "/hpux32",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
# Frank Geurts <frank.geurts@nl.abnamro.com> has patiently assisted
|
|
|
|
# with debugging of the following config.
|
2015-03-10 23:58:50 +00:00
|
|
|
"hpux64-ia64-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("ia64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-Ae +DD64 +Olit=all -z -DB_ENDIAN",
|
|
|
|
debug => "+O0 +d -g",
|
|
|
|
release => "+O3"),
|
|
|
|
threads("-D_REENTRANT")),
|
|
|
|
ex_libs => add("-ldl", threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "hpux-shared",
|
|
|
|
shared_cflag => "+Z",
|
|
|
|
shared_ldflag => "+DD64 -b",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
multilib => "/hpux64",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
# GCC builds...
|
2015-03-10 23:58:50 +00:00
|
|
|
"hpux-ia64-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("ia64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-DB_ENDIAN",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
|
|
|
threads("-pthread")),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-ldl"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "hpux-shared",
|
|
|
|
shared_cflag => "-fpic",
|
|
|
|
shared_ldflag => "-shared",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
multilib => "/hpux32",
|
|
|
|
},
|
|
|
|
"hpux64-ia64-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("ia64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => picker(default => "-mlp64 -DB_ENDIAN",
|
|
|
|
debug => "-O0 -g",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
release => "-O3",
|
|
|
|
threads("-pthread")),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-ldl"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "hpux-shared",
|
|
|
|
shared_cflag => "-fpic",
|
|
|
|
shared_ldflag => "-mlp64 -shared",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
multilib => "/hpux64",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
#### HP MPE/iX http://jazz.external.hp.com/src/openssl/
|
2015-03-10 23:58:50 +00:00
|
|
|
"MPE/iX-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
|
|
|
cflags => "-D_ENDIAN -DBN_DIV2W -O3 -D_POSIX_SOURCE -D_SOCKET_SOURCE -I/SYSLOG/PUB",
|
|
|
|
sys_id => "MPE",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-L/SYSLOG/PUB -lsyslog -lsocket -lcurses"),
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### DEC Alpha OSF/1/Tru64 targets.
|
2015-03-10 23:58:50 +00:00
|
|
|
"osf1-alpha-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("alpha_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
|
|
|
cflags => "-O3",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "alpha-osf1-shared",
|
|
|
|
shared_extension => ".so",
|
|
|
|
},
|
|
|
|
"osf1-alpha-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("alpha_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
|
|
|
cflags => "-std1 -tune host -O4 -readonly_strings",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "alpha-osf1-shared",
|
|
|
|
shared_extension => ".so",
|
|
|
|
},
|
|
|
|
"tru64-alpha-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("alpha_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("-std1 -tune host -fast -readonly_strings",
|
|
|
|
threads("-pthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "alpha-osf1-shared",
|
|
|
|
shared_ldflag => "-msym",
|
|
|
|
shared_extension => ".so",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
####
|
|
|
|
#### Variety of LINUX:-)
|
|
|
|
####
|
|
|
|
# *-generic* is endian-neutral target, but ./config is free to
|
|
|
|
# throw in -D[BL]_ENDIAN, whichever appropriate...
|
2015-03-10 23:58:50 +00:00
|
|
|
"linux-generic32" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-Wall",
|
|
|
|
debug => "-O0 -g -DBN_DEBUG -DREF_DEBUG -DCONF_DEBUG",
|
|
|
|
release => "-O3"),
|
|
|
|
threads("-pthread")),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-ldl"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "linux-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
"linux-generic64" => {
|
|
|
|
inherit_from => [ "linux-generic32" ],
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHAR",
|
2015-03-16 21:33:36 +00:00
|
|
|
},
|
|
|
|
|
2015-03-10 23:58:50 +00:00
|
|
|
"linux-ppc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "linux-generic32", asm("ppc32_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "linux32",
|
2015-03-16 21:33:36 +00:00
|
|
|
},
|
|
|
|
"linux-ppc64" => {
|
|
|
|
inherit_from => [ "linux-generic64", asm("ppc64_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-m64 -DB_ENDIAN"),
|
2015-03-16 21:33:36 +00:00
|
|
|
perlasm_scheme => "linux64",
|
|
|
|
shared_ldflag => "-m64",
|
|
|
|
multilib => "64",
|
|
|
|
},
|
|
|
|
"linux-ppc64le" => {
|
|
|
|
inherit_from => [ "linux-generic64", asm("ppc64_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-m64 -DL_ENDIAN"),
|
2015-03-16 21:33:36 +00:00
|
|
|
perlasm_scheme => "linux64le",
|
|
|
|
shared_ldflag => "-m64",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-10 23:58:50 +00:00
|
|
|
"linux-armv4" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
################################################################
|
|
|
|
# Note that -march is not among compiler options in linux-armv4
|
|
|
|
# target description. Not specifying one is intentional to give
|
|
|
|
# you choice to:
|
|
|
|
#
|
|
|
|
# a) rely on your compiler default by not specifying one;
|
|
|
|
# b) specify your target platform explicitly for optimal
|
|
|
|
# performance, e.g. -march=armv6 or -march=armv7-a;
|
|
|
|
# c) build "universal" binary that targets *range* of platforms
|
|
|
|
# by specifying minimum and maximum supported architecture;
|
|
|
|
#
|
|
|
|
# As for c) option. It actually makes no sense to specify
|
|
|
|
# maximum to be less than ARMv7, because it's the least
|
|
|
|
# requirement for run-time switch between platform-specific
|
|
|
|
# code paths. And without run-time switch performance would be
|
|
|
|
# equivalent to one for minimum. Secondly, there are some
|
|
|
|
# natural limitations that you'd have to accept and respect.
|
|
|
|
# Most notably you can *not* build "universal" binary for
|
|
|
|
# big-endian platform. This is because ARMv7 processor always
|
|
|
|
# picks instructions in little-endian order. Another similar
|
|
|
|
# limitation is that -mthumb can't "cross" -march=armv6t2
|
|
|
|
# boundary, because that's where it became Thumb-2. Well, this
|
|
|
|
# limitation is a bit artificial, because it's not really
|
|
|
|
# impossible, but it's deemed too tricky to support. And of
|
|
|
|
# course you have to be sure that your binutils are actually
|
|
|
|
# up to the task of handling maximum target platform. With all
|
|
|
|
# this in mind here is an example of how to configure
|
|
|
|
# "universal" build:
|
|
|
|
#
|
|
|
|
# ./Configure linux-armv4 -march=armv6 -D__ARM_MAX_ARCH__=8
|
|
|
|
#
|
|
|
|
inherit_from => [ "linux-generic32", asm("armv4_asm") ],
|
|
|
|
perlasm_scheme => "linux32",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"linux-aarch64" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "linux-generic64", asm("aarch64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "linux64",
|
|
|
|
},
|
2015-09-23 14:43:55 +00:00
|
|
|
"linux-arm64ilp32" => { # https://wiki.linaro.org/Platform/arm64-ilp32
|
|
|
|
inherit_from => [ "linux-generic32", asm("aarch64_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-mabi=ilp32"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT RC4_CHAR",
|
2015-09-23 14:43:55 +00:00
|
|
|
perlasm_scheme => "linux64",
|
|
|
|
shared_ldflag => "-mabi=ilp32",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
2015-03-10 23:58:50 +00:00
|
|
|
"linux-mips32" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
# Configure script adds minimally required -march for assembly
|
|
|
|
# support, if no -march was specified at command line.
|
|
|
|
inherit_from => [ "linux-generic32", asm("mips32_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-mabi=32 -DBN_DIV3W"),
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "o32",
|
2015-03-16 21:33:36 +00:00
|
|
|
shared_ldflag => "-mabi=32",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
# mips32 and mips64 below refer to contemporary MIPS Architecture
|
|
|
|
# specifications, MIPS32 and MIPS64, rather than to kernel bitness.
|
2015-03-10 23:58:50 +00:00
|
|
|
"linux-mips64" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "linux-generic32", asm("mips64_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-mabi=n32 -DBN_DIV3W"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "n32",
|
|
|
|
shared_ldflag => "-mabi=n32",
|
|
|
|
multilib => "32",
|
|
|
|
},
|
|
|
|
"linux64-mips64" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "linux-generic64", asm("mips64_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-mabi=64 -DBN_DIV3W"),
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "64",
|
|
|
|
shared_ldflag => "-mabi=64",
|
|
|
|
multilib => "64",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
|
|
|
#### IA-32 targets...
|
2015-03-10 23:58:50 +00:00
|
|
|
"linux-elf" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "linux-generic32", asm("x86_elf_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add(picker(default => "-DL_ENDIAN",
|
|
|
|
release => "-fomit-frame-pointer")),
|
|
|
|
ex_libs => add(picker(debug => "-lefence")),
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"linux-aout" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("x86_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add(picker(default => "-DL_ENDIAN -Wall",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O3 -fomit-frame-pointer")),
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "a.out",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
2015-03-10 23:58:50 +00:00
|
|
|
"linux-x86_64" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "linux-generic64", asm("x86_64_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-m64 -DL_ENDIAN"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "elf",
|
2015-03-16 21:33:36 +00:00
|
|
|
shared_ldflag => "-m64",
|
2015-03-10 23:58:50 +00:00
|
|
|
multilib => "64",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
"linux-x86_64-clang" => {
|
|
|
|
inherit_from => [ "linux-x86_64" ],
|
|
|
|
cc => "clang",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-Wextra -Qunused-arguments"),
|
2015-03-16 21:33:36 +00:00
|
|
|
},
|
2015-03-10 23:58:50 +00:00
|
|
|
"linux-x32" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "linux-generic32", asm("x86_64_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-mx32 -DL_ENDIAN"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "elf",
|
|
|
|
shared_ldflag => "-mx32",
|
|
|
|
multilib => "x32",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
|
|
|
"linux-ia64" => {
|
|
|
|
inherit_from => [ "linux-generic64", asm("ia64_asm") ],
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2015-03-16 21:33:36 +00:00
|
|
|
},
|
|
|
|
|
2015-03-10 23:58:50 +00:00
|
|
|
"linux64-s390x" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "linux-generic64", asm("s390x_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-m64 -DB_ENDIAN"),
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "64",
|
|
|
|
shared_ldflag => "-m64",
|
|
|
|
multilib => "64",
|
|
|
|
},
|
|
|
|
"linux32-s390x" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
#### So called "highgprs" target for z/Architecture CPUs
|
|
|
|
# "Highgprs" is kernel feature first implemented in Linux
|
|
|
|
# 2.6.32, see /proc/cpuinfo. The idea is to preserve most
|
|
|
|
# significant bits of general purpose registers not only
|
|
|
|
# upon 32-bit process context switch, but even on
|
|
|
|
# asynchronous signal delivery to such process. This makes
|
|
|
|
# it possible to deploy 64-bit instructions even in legacy
|
|
|
|
# application context and achieve better [or should we say
|
|
|
|
# adequate] performance. The build is binary compatible with
|
|
|
|
# linux-generic32, and the idea is to be able to install the
|
|
|
|
# resulting libcrypto.so alongside generic one, e.g. as
|
|
|
|
# /lib/highgprs/libcrypto.so.x.y, for ldconfig and run-time
|
|
|
|
# linker to autodiscover. Unfortunately it doesn't work just
|
|
|
|
# yet, because of couple of bugs in glibc
|
|
|
|
# sysdeps/s390/dl-procinfo.c affecting ldconfig and ld.so.1...
|
|
|
|
#
|
|
|
|
inherit_from => [ "linux-generic32", asm("s390x_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-m31 -Wa,-mzarch -DB_ENDIAN"),
|
2015-03-16 21:33:36 +00:00
|
|
|
bn_obj => sub { my $r=join(" ",@_); $r=~s/bn\-s390x/bn_asm/; $r; },
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "31",
|
|
|
|
shared_ldflag => "-m31",
|
|
|
|
multilib => "/highgprs",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
|
|
|
#### SPARC Linux setups
|
|
|
|
# Ray Miller <ray.miller@computing-services.oxford.ac.uk> has
|
|
|
|
# patiently assisted with debugging of following two configs.
|
2015-03-10 23:58:50 +00:00
|
|
|
"linux-sparcv8" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "linux-generic32", asm("sparcv8_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-mcpu=v8 -DB_ENDIAN -DBN_DIV2W"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"linux-sparcv9" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
# it's a real mess with -mcpu=ultrasparc option under Linux,
|
|
|
|
# but -Wa,-Av8plus should do the trick no matter what.
|
|
|
|
inherit_from => [ "linux-generic32", asm("sparcv9_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-m32 -mcpu=ultrasparc -Wa,-Av8plus -DB_ENDIAN -DBN_DIV2W"),
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_ldflag => "-m32",
|
|
|
|
},
|
|
|
|
"linux64-sparcv9" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
# GCC 3.1 is a requirement
|
|
|
|
inherit_from => [ "linux-generic64", asm("sparcv9_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-m64 -mcpu=ultrasparc -DB_ENDIAN"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_ldflag => "-m64",
|
|
|
|
multilib => "64",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
2015-03-10 23:58:50 +00:00
|
|
|
"linux-alpha-gcc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "linux-generic64", asm("alpha_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-DL_ENDIAN"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"linux-c64xplus" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-16 21:33:36 +00:00
|
|
|
# TI_CGT_C6000_7.3.x is a requirement
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cl6x",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("--linux -ea=.s -eo=.o -mv6400+ -o2 -ox -ms -pden -DOPENSSL_SMALL_FOOTPRINT",
|
|
|
|
threads("-D_REENTRANT")),
|
2015-03-10 23:58:50 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-12-15 20:52:01 +00:00
|
|
|
cpuid_asm_src => "c64xpluscpuid.s",
|
|
|
|
bn_asm_src => "asm/bn-c64xplus.asm c64xplus-gf2m.s",
|
|
|
|
aes_asm_src => "aes-c64xplus.s aes_cbc.c aes-ctr.fake",
|
|
|
|
sha1_asm_src => "sha1-c64xplus.s sha256-c64xplus.s sha512-c64xplus.s",
|
|
|
|
rc4_asm_src => "rc4-c64xplus.s",
|
|
|
|
modes_asm_src => "ghash-c64xplus.s",
|
|
|
|
chacha_asm_src => "chacha-c64xplus.s",
|
|
|
|
poly1305_asm_src => "poly1305-c64xplus.s",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "void",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "linux-shared",
|
|
|
|
shared_cflag => "--pic",
|
|
|
|
shared_ldflag => "-z --sysv --shared",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
ranlib => "true",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### Android: linux-* but without pointers to headers and libs.
|
2015-03-30 14:47:57 +00:00
|
|
|
#
|
|
|
|
# It takes pair of prior-set environment variables to make it work:
|
|
|
|
#
|
|
|
|
# CROSS_SYSROOT=/some/where/android-ndk-<ver>/platforms/android-<apiver>/arch-<
|
|
|
|
# CROSS_COMPILE=<prefix>
|
|
|
|
#
|
|
|
|
# As well as PATH adjusted to cover ${CROSS_COMPILE}gcc and company.
|
|
|
|
# For example to compile for ICS and ARM with NDK 10d, you'd:
|
|
|
|
#
|
|
|
|
# ANDROID_NDK=/some/where/android-ndk-10d
|
|
|
|
# CROSS_SYSROOT=$ANDROID_NDK/platforms/android-14/arch-arm
|
|
|
|
# CROSS_COMPILE=arm-linux-adroideabi-
|
|
|
|
# PATH=$ANDROID_NDK/toolchains/arm-linux-androideabi-4.8/prebuild/linux-x86_64/
|
|
|
|
#
|
2015-03-10 23:58:50 +00:00
|
|
|
"android" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "linux-generic32" ],
|
2015-03-30 14:47:57 +00:00
|
|
|
# Special note about unconditional -fPIC and -pie. The underlying
|
|
|
|
# reason is that Lollipop refuses to run non-PIE. But what about
|
|
|
|
# older systems and NDKs? -fPIC was never problem, so the only
|
|
|
|
# concern if -pie. Older toolchains, e.g. r4, appear to handle it
|
|
|
|
# and binaries turn mostly functional. "Mostly" means that oldest
|
|
|
|
# Androids, such as Froyo, fail to handle executable, but newer
|
|
|
|
# systems are perfectly capable of executing binaries targeting
|
|
|
|
# Froyo. Keep in mind that in the nutshell Android builds are
|
|
|
|
# about JNI, i.e. shared libraries, not applications.
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => picker(default => "-mandroid -fPIC --sysroot=\$(CROSS_SYSROOT) -Wa,--noexecstack -Wall",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
2016-01-29 17:07:37 +00:00
|
|
|
lflags => "-pie",
|
2015-03-30 14:47:57 +00:00
|
|
|
shared_cflag => "",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"android-x86" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "android", asm("x86_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add(picker(release => "-fomit-frame-pointer")),
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-03-16 21:33:36 +00:00
|
|
|
perlasm_scheme => "android",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-03-30 14:47:57 +00:00
|
|
|
################################################################
|
|
|
|
# Contemporary Android applications can provide multiple JNI
|
|
|
|
# providers in .apk, targeting multiple architectures. Among
|
|
|
|
# them there is "place" for two ARM flavours: generic eabi and
|
|
|
|
# armv7-a/hard-float. However, it should be noted that OpenSSL's
|
|
|
|
# ability to engage NEON is not constrained by ABI choice, nor
|
|
|
|
# is your ability to call OpenSSL from your application code
|
|
|
|
# compiled with floating-point ABI other than default 'soft'.
|
|
|
|
# [Latter thanks to __attribute__((pcs("aapcs"))) declaration.]
|
|
|
|
# This means that choice of ARM libraries you provide in .apk
|
|
|
|
# is driven by application needs. For example if application
|
|
|
|
# itself benefits from NEON or is floating-point intensive, then
|
|
|
|
# it might be appropriate to provide both libraries. Otherwise
|
|
|
|
# just generic eabi would do. But in latter case it would be
|
|
|
|
# appropriate to
|
|
|
|
#
|
|
|
|
# ./Configure android-armeabi -D__ARM_MAX_ARCH__=8
|
|
|
|
#
|
|
|
|
# in order to build "universal" binary and allow OpenSSL take
|
|
|
|
# advantage of NEON when it's available.
|
|
|
|
#
|
|
|
|
"android-armeabi" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "android", asm("armv4_asm") ],
|
2015-03-30 14:47:57 +00:00
|
|
|
},
|
2015-03-10 23:58:50 +00:00
|
|
|
"android-mips" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "android", asm("mips32_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "o32",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-04-02 21:18:10 +00:00
|
|
|
"android64" => {
|
|
|
|
inherit_from => [ "linux-generic64" ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => picker(default => "-mandroid -fPIC --sysroot=\$(CROSS_SYSROOT) -Wa,--noexecstack -Wall",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
2016-01-29 17:07:37 +00:00
|
|
|
lflags => "-pie",
|
2015-04-02 21:18:10 +00:00
|
|
|
shared_cflag => "",
|
|
|
|
},
|
|
|
|
"android64-aarch64" => {
|
|
|
|
inherit_from => [ "android64", asm("aarch64_asm") ],
|
|
|
|
perlasm_scheme => "linux64",
|
|
|
|
},
|
|
|
|
|
2015-03-18 15:56:38 +00:00
|
|
|
#### *BSD
|
2015-03-10 23:58:50 +00:00
|
|
|
"BSD-generic32" => {
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
# As for thread cflag. Idea is to maintain "collective" set of
|
2015-03-18 15:56:38 +00:00
|
|
|
# flags, which would cover all BSD flavors. -pthread applies
|
|
|
|
# to them all, but is treated differently. OpenBSD expands is
|
|
|
|
# as -D_POSIX_THREAD -lc_r, which is sufficient. FreeBSD 4.x
|
|
|
|
# expands it as -lc_r, which has to be accompanied by explicit
|
|
|
|
# -D_THREAD_SAFE and sometimes -D_REENTRANT. FreeBSD 5.x
|
|
|
|
# expands it as -lc_r, which seems to be sufficient?
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-08-02 01:21:46 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-Wall",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
|
|
|
threads("-pthread -D_THREAD_SAFE -D_REENTRANT")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "bsd-gcc-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
"BSD-generic64" => {
|
|
|
|
inherit_from => [ "BSD-generic32" ],
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
|
|
|
"BSD-x86" => {
|
|
|
|
inherit_from => [ "BSD-generic32", asm("x86_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add(picker(default => "-DL_ENDIAN",
|
|
|
|
release => "-fomit-frame-pointer")),
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_target => "bsd-shared",
|
2015-03-16 21:33:36 +00:00
|
|
|
perlasm_scheme => "a.out",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
"BSD-x86-elf" => {
|
|
|
|
inherit_from => [ "BSD-x86" ],
|
|
|
|
perlasm_scheme => "elf",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
"BSD-sparcv8" => {
|
|
|
|
inherit_from => [ "BSD-generic32", asm("sparcv8_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-mcpu=v8 -DB_ENDIAN"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"BSD-sparc64" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
# -DMD32_REG_T=int doesn't actually belong in sparc64 target, it
|
|
|
|
# simply *happens* to work around a compiler bug in gcc 3.3.3,
|
|
|
|
# triggered by RIPEMD160 code.
|
|
|
|
inherit_from => [ "BSD-generic64", asm("sparcv9_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-DB_ENDIAN -DMD32_REG_T=int"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
2015-03-10 23:58:50 +00:00
|
|
|
"BSD-ia64" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "BSD-generic64", asm("ia64_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add_before("-DL_ENDIAN"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
2015-03-10 23:58:50 +00:00
|
|
|
"BSD-x86_64" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "BSD-generic64", asm("x86_64_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add_before("-DL_ENDIAN"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "elf",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-10 23:58:50 +00:00
|
|
|
"bsdi-elf-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("x86_elf_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
2016-02-22 20:02:42 +00:00
|
|
|
cflags => "-DPERL5 -DL_ENDIAN -fomit-frame-pointer -O3 -Wall",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-ldl"),
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "bsd-gcc-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-10 23:58:50 +00:00
|
|
|
"nextstep" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
|
|
|
cflags => "-O -Wall",
|
|
|
|
unistd => "<libc.h>",
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"nextstep3.3" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
|
|
|
cflags => "-O3 -Wall",
|
|
|
|
unistd => "<libc.h>",
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
# QNX
|
2015-03-10 23:58:50 +00:00
|
|
|
"qnx4" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
|
|
|
cflags => "-DL_ENDIAN -DTERMIO",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"QNX6" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lsocket"),
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "bsd-gcc-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
|
|
|
"QNX6-i386" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("x86_elf_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
|
|
|
cflags => "-DL_ENDIAN -O2 -Wall",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lsocket"),
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "bsd-gcc-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
#### SCO/Caldera targets.
|
|
|
|
#
|
|
|
|
# Originally we had like unixware-*, unixware-*-pentium, unixware-*-p6, etc.
|
|
|
|
# Now we only have blended unixware-* as it's the only one used by ./config.
|
|
|
|
# If you want to optimize for particular microarchitecture, bypass ./config
|
|
|
|
# and './Configure unixware-7 -Kpentium_pro' or whatever appropriate.
|
|
|
|
# Note that not all targets include assembler support. Mostly because of
|
|
|
|
# lack of motivation to support out-of-date platforms with out-of-date
|
|
|
|
# compiler drivers and assemblers. Tim Rice <tim@multitalents.net> has
|
|
|
|
# patiently assisted to debug most of it.
|
|
|
|
#
|
|
|
|
# UnixWare 2.0x fails destest with -O.
|
2015-03-10 23:58:50 +00:00
|
|
|
"unixware-2.0" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("-DFILIO_H -DNO_STRINGS_H",
|
|
|
|
threads("-Kthread")),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lsocket -lnsl -lresolv -lx"),
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "uithreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"unixware-2.1" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("-O -DFILIO_H",
|
|
|
|
threads("-Kthread")),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lsocket -lnsl -lresolv -lx"),
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "uithreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"unixware-7" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("x86_elf_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("-O -DFILIO_H -Kalloca",
|
|
|
|
threads("-Kthread")),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lsocket -lnsl"),
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "uithreads",
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "elf-1",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "svr5-shared",
|
|
|
|
shared_cflag => "-Kpic",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
|
|
|
"unixware-7-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("x86_elf_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("-DL_ENDIAN -DFILIO_H -O3 -fomit-frame-pointer -Wall",
|
|
|
|
threads("-D_REENTRANT")),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lsocket -lnsl"),
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "elf-1",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "gnu-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
# SCO 5 - Ben Laurie <ben@algroup.co.uk> says the -O breaks the SCO cc.
|
2015-03-10 23:58:50 +00:00
|
|
|
"sco5-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("x86_elf_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
|
|
|
cflags => "-belf",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lsocket -lnsl"),
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "elf-1",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "svr3-shared",
|
|
|
|
shared_cflag => "-Kpic",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
|
|
|
"sco5-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("x86_elf_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
|
|
|
cflags => "-O3 -fomit-frame-pointer",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lsocket -lnsl"),
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "elf-1",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "svr3-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
#### IBM's AIX.
|
2015-03-10 23:58:50 +00:00
|
|
|
"aix-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("ppc32_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-DB_ENDIAN",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O"),
|
|
|
|
threads("-pthread")),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "AIX",
|
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "aix32",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "aix-shared",
|
|
|
|
shared_ldflag => "-shared -Wl,-G",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
arflags => "-X32",
|
|
|
|
},
|
|
|
|
"aix64-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("ppc64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-maix64 -DB_ENDIAN",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O"),
|
|
|
|
threads("-pthread")),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "AIX",
|
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "aix64",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "aix-shared",
|
|
|
|
shared_ldflag => "-maix64 -shared -Wl,-G",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
arflags => "-X64",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
# Below targets assume AIX 5. Idea is to effectively disregard
|
|
|
|
# $OBJECT_MODE at build time. $OBJECT_MODE is respected at
|
|
|
|
# ./config stage!
|
2015-03-10 23:58:50 +00:00
|
|
|
"aix-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("ppc32_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-q32 -DB_ENDIAN -qmaxmem=16384 -qro -qroconst",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O"),
|
|
|
|
threads("-qthreaded -D_THREAD_SAFE")),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "AIX",
|
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "aix32",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "aix-shared",
|
|
|
|
shared_ldflag => "-q32 -G",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
arflags => "-X 32",
|
|
|
|
},
|
|
|
|
"aix64-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("ppc64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-q64 -DB_ENDIAN -qmaxmem=16384 -qro -qroconst",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O"),
|
|
|
|
threads("-qthreaded -D_THREAD_SAFE")),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "AIX",
|
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "aix64",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "aix-shared",
|
|
|
|
shared_ldflag => "-q64 -G",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
arflags => "-X 64",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
# SIEMENS BS2000/OSD: an EBCDIC-based mainframe
|
2015-03-10 23:58:50 +00:00
|
|
|
"BS2000-OSD" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "c89",
|
|
|
|
cflags => "-O -XLLML -XLLMK -XL -DB_ENDIAN -DCHARSET_EBCDIC",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lsocket -lnsl"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "THIRTY_TWO_BIT RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
# OS/390 Unix an EBCDIC-based Unix system on IBM mainframe
|
|
|
|
# You need to compile using the c89.sh wrapper in the tools directory, because the
|
|
|
|
# IBM compiler does not like the -L switch after any object modules.
|
|
|
|
#
|
2015-03-10 23:58:50 +00:00
|
|
|
"OS390-Unix" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "c89.sh",
|
|
|
|
cflags => "-O -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -D_ALL_SOURCE",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "THIRTY_TWO_BIT RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### Visual C targets
|
2015-02-24 22:40:22 +00:00
|
|
|
#
|
|
|
|
# Win64 targets, WIN64I denotes IA-64 and WIN64A - AMD64
|
|
|
|
#
|
|
|
|
# Note about -wd4090, disable warning C4090. This warning returns false
|
|
|
|
# positives in some situations. Disabling it altogether masks both
|
|
|
|
# legitimate and false cases, but as we compile on multiple platforms,
|
|
|
|
# we rely on other compilers to catch legitimate cases.
|
2015-03-16 21:33:36 +00:00
|
|
|
"VC-common" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_Windows" ],
|
2015-03-16 21:33:36 +00:00
|
|
|
template => 1,
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cl",
|
2015-03-16 21:33:36 +00:00
|
|
|
cflags => "-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE",
|
2016-03-02 13:10:21 +00:00
|
|
|
shared_target => "win-shared", # meaningless except it gives Configure a hint
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "win32",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
"VC-WIN64I" => {
|
|
|
|
inherit_from => [ "VC-common", asm("ia64_asm") ],
|
2016-02-24 23:17:59 +00:00
|
|
|
cflags => add("-DUNICODE -D_UNICODE"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "WIN64I",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT EXPORT_VAR_AS_FN",
|
2015-03-16 21:33:36 +00:00
|
|
|
bn_obj => sub { my $r=join(" ",@_); $r=~s/bn\-//; $r; },
|
|
|
|
rc4_obj => "",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "ias",
|
2016-02-27 10:25:33 +00:00
|
|
|
build_scheme => add("VC-W64", { separator => undef }),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"VC-WIN64A" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "VC-common", asm("x86_64_asm") ],
|
2016-02-24 23:17:59 +00:00
|
|
|
cflags => add("-DUNICODE -D_UNICODE"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "WIN64A",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT EXPORT_VAR_AS_FN",
|
2015-03-16 21:33:36 +00:00
|
|
|
bn_obj => sub { my $r=join(" ",@_); $r=~s/x86_64\-gcc/bn_asm/; $r; },
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "auto",
|
2016-02-27 10:25:33 +00:00
|
|
|
build_scheme => add("VC-W64", { separator => undef }),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"VC-WIN32" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
# x86 Win32 target defaults to ANSI API, if you want UNICODE,
|
|
|
|
# configure with 'perl Configure VC-WIN32 -DUNICODE -D_UNICODE'
|
|
|
|
inherit_from => [ "VC-common", asm("x86_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "WIN32",
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG EXPORT_VAR_AS_FN",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "win32n",
|
2016-02-27 10:25:33 +00:00
|
|
|
build_scheme => add("VC-W32", { separator => undef }),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"VC-CE" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_Windows" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cl",
|
|
|
|
sys_id => "WINCE",
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG EXPORT_VAR_AS_FN",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "win32",
|
2016-02-27 10:25:33 +00:00
|
|
|
build_scheme => add("VC-WCE", { separator => undef }),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### Borland C++ 4.5
|
2015-03-10 23:58:50 +00:00
|
|
|
"BC-32" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_Windows" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "bcc32",
|
|
|
|
sys_id => "WIN32",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG EXPORT_VAR_AS_FN",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "win32",
|
2016-02-27 10:25:33 +00:00
|
|
|
build_scheme => add("BC", { separator => undef }),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### MinGW
|
2015-03-10 23:58:50 +00:00
|
|
|
"mingw" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("x86_asm"),
|
2016-02-22 12:52:46 +00:00
|
|
|
sub { $disabled{shared} ? () : "x86_uplink" } ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m32 -Wall",
|
|
|
|
debug => "-g -O0",
|
|
|
|
release => "-O3 -fomit-frame-pointer"),
|
|
|
|
threads("-D_MT")),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "MINGW32",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lws2_32 -lgdi32 -lcrypt32"),
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG EXPORT_VAR_AS_FN",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "winthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "coff",
|
|
|
|
dso_scheme => "win32",
|
Big rename fest of MingW shared libraries
So far, MingW shared libraries were named like this
libeay32.dll + libeay32.dll.a
ssleay32.dll + ssleay32.dll.a
That naming scheme is antiquated, a reminicense of SSLeay. We're
therefore changing the scheme to something that's more like the rest
of OpenSSL.
There are two factors to remember:
- Windows libraries have no recorded SOvers, which means that the
shared library version must be encoded in the name. According to
some, it's unwise to encode extra periods in a Windows file name,
so we convert version number periods to underscores.
- MingW has multilib ability. However, DLLs need to reside with the
binaries that use them, so to allow both 32-bit and 64-bit DLLs to
reside in the same place, we add '-x64' in the name of the 64-bit
ones.
The resulting name scheme (for SOver 1.1) is this:
on x86:
libcrypto-1_1.dll + libcrypto.dll.a
libssl-1_1.dll + libssl.dll.a
on x86_64:
libcrypto-1_1-x64.dll + libcrypto.dll.a
libssl-1_1-x64.dll + libssl.dll.a
An observation is that the import lib is the same for both
architectures. Not to worry, though, as they will be installed in
PREFIX/lib/ for x86 and PREFIX/lib64/ for x86_64.
As a side effect, MingW got its own targets in Makefile.shared.
link_dso.mingw-shared and link_app.mingw-shared are aliases for the
corresponding cygwin-shared targets. link_shlib.mingw-shared is,
however, a target separated from the cygwin one.
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-16 19:37:28 +00:00
|
|
|
shared_target => "mingw-shared",
|
2016-02-24 23:17:59 +00:00
|
|
|
shared_cflag => add("-D_WINDLL"),
|
2016-02-05 14:14:45 +00:00
|
|
|
shared_ldflag => "-static-libgcc",
|
2016-02-05 14:17:33 +00:00
|
|
|
shared_rcflag => "--target=pe-i386",
|
2016-01-30 04:45:29 +00:00
|
|
|
shared_extension => ".dll",
|
Big rename fest of MingW shared libraries
So far, MingW shared libraries were named like this
libeay32.dll + libeay32.dll.a
ssleay32.dll + ssleay32.dll.a
That naming scheme is antiquated, a reminicense of SSLeay. We're
therefore changing the scheme to something that's more like the rest
of OpenSSL.
There are two factors to remember:
- Windows libraries have no recorded SOvers, which means that the
shared library version must be encoded in the name. According to
some, it's unwise to encode extra periods in a Windows file name,
so we convert version number periods to underscores.
- MingW has multilib ability. However, DLLs need to reside with the
binaries that use them, so to allow both 32-bit and 64-bit DLLs to
reside in the same place, we add '-x64' in the name of the 64-bit
ones.
The resulting name scheme (for SOver 1.1) is this:
on x86:
libcrypto-1_1.dll + libcrypto.dll.a
libssl-1_1.dll + libssl.dll.a
on x86_64:
libcrypto-1_1-x64.dll + libcrypto.dll.a
libssl-1_1-x64.dll + libssl.dll.a
An observation is that the import lib is the same for both
architectures. Not to worry, though, as they will be installed in
PREFIX/lib/ for x86 and PREFIX/lib64/ for x86_64.
As a side effect, MingW got its own targets in Makefile.shared.
link_dso.mingw-shared and link_app.mingw-shared are aliases for the
corresponding cygwin-shared targets. link_shlib.mingw-shared is,
however, a target separated from the cygwin one.
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-16 19:37:28 +00:00
|
|
|
multilib => "",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"mingw64" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
# As for OPENSSL_USE_APPLINK. Applink makes it possible to use
|
|
|
|
# .dll compiled with one compiler with application compiled with
|
|
|
|
# another compiler. It's possible to engage Applink support in
|
|
|
|
# mingw64 build, but it's not done, because till mingw64
|
|
|
|
# supports structured exception handling, one can't seriously
|
|
|
|
# consider its binaries for using with non-mingw64 run-time
|
|
|
|
# environment. And as mingw64 is always consistent with itself,
|
|
|
|
# Applink is never engaged and can as well be omitted.
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("x86_64_asm") ],
|
2015-03-16 21:33:36 +00:00
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "-DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall",
|
|
|
|
debug => "-g -O0",
|
|
|
|
release => "-O3"),
|
|
|
|
threads("-D_MT")),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "MINGW64",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lws2_32 -lgdi32 -lcrypt32"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT EXPORT_VAR_AS_FN",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "winthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "mingw64",
|
|
|
|
dso_scheme => "win32",
|
Big rename fest of MingW shared libraries
So far, MingW shared libraries were named like this
libeay32.dll + libeay32.dll.a
ssleay32.dll + ssleay32.dll.a
That naming scheme is antiquated, a reminicense of SSLeay. We're
therefore changing the scheme to something that's more like the rest
of OpenSSL.
There are two factors to remember:
- Windows libraries have no recorded SOvers, which means that the
shared library version must be encoded in the name. According to
some, it's unwise to encode extra periods in a Windows file name,
so we convert version number periods to underscores.
- MingW has multilib ability. However, DLLs need to reside with the
binaries that use them, so to allow both 32-bit and 64-bit DLLs to
reside in the same place, we add '-x64' in the name of the 64-bit
ones.
The resulting name scheme (for SOver 1.1) is this:
on x86:
libcrypto-1_1.dll + libcrypto.dll.a
libssl-1_1.dll + libssl.dll.a
on x86_64:
libcrypto-1_1-x64.dll + libcrypto.dll.a
libssl-1_1-x64.dll + libssl.dll.a
An observation is that the import lib is the same for both
architectures. Not to worry, though, as they will be installed in
PREFIX/lib/ for x86 and PREFIX/lib64/ for x86_64.
As a side effect, MingW got its own targets in Makefile.shared.
link_dso.mingw-shared and link_app.mingw-shared are aliases for the
corresponding cygwin-shared targets. link_shlib.mingw-shared is,
however, a target separated from the cygwin one.
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-16 19:37:28 +00:00
|
|
|
shared_target => "mingw-shared",
|
2016-02-24 23:17:59 +00:00
|
|
|
shared_cflag => add("-D_WINDLL"),
|
2016-02-05 14:14:45 +00:00
|
|
|
shared_ldflag => "-static-libgcc",
|
2016-02-05 14:17:33 +00:00
|
|
|
shared_rcflag => "--target=pe-x86-64",
|
2016-01-30 04:45:29 +00:00
|
|
|
shared_extension => ".dll",
|
Big rename fest of MingW shared libraries
So far, MingW shared libraries were named like this
libeay32.dll + libeay32.dll.a
ssleay32.dll + ssleay32.dll.a
That naming scheme is antiquated, a reminicense of SSLeay. We're
therefore changing the scheme to something that's more like the rest
of OpenSSL.
There are two factors to remember:
- Windows libraries have no recorded SOvers, which means that the
shared library version must be encoded in the name. According to
some, it's unwise to encode extra periods in a Windows file name,
so we convert version number periods to underscores.
- MingW has multilib ability. However, DLLs need to reside with the
binaries that use them, so to allow both 32-bit and 64-bit DLLs to
reside in the same place, we add '-x64' in the name of the 64-bit
ones.
The resulting name scheme (for SOver 1.1) is this:
on x86:
libcrypto-1_1.dll + libcrypto.dll.a
libssl-1_1.dll + libssl.dll.a
on x86_64:
libcrypto-1_1-x64.dll + libcrypto.dll.a
libssl-1_1-x64.dll + libssl.dll.a
An observation is that the import lib is the same for both
architectures. Not to worry, though, as they will be installed in
PREFIX/lib/ for x86 and PREFIX/lib64/ for x86_64.
As a side effect, MingW got its own targets in Makefile.shared.
link_dso.mingw-shared and link_app.mingw-shared are aliases for the
corresponding cygwin-shared targets. link_shlib.mingw-shared is,
however, a target separated from the cygwin one.
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-16 19:37:28 +00:00
|
|
|
multilib => "64",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-09-09 02:51:17 +00:00
|
|
|
#### UEFI
|
|
|
|
"UEFI" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-09-09 02:51:17 +00:00
|
|
|
cc => "cc",
|
|
|
|
cflags => "-DL_ENDIAN -O",
|
|
|
|
sys_id => "UEFI",
|
|
|
|
},
|
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### UWIN
|
2015-03-10 23:58:50 +00:00
|
|
|
"UWIN" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
|
|
|
cflags => "-DTERMIOS -DL_ENDIAN -O -Wall",
|
|
|
|
sys_id => "UWIN",
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "win32",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### Cygwin
|
2016-01-17 16:48:53 +00:00
|
|
|
"Cygwin-x86" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("x86_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => picker(default => "-DTERMIOS -DL_ENDIAN -Wall",
|
|
|
|
debug => "-g -O0",
|
|
|
|
release => "-O3 -fomit-frame-pointer"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "CYGWIN",
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "coff",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "cygwin-shared",
|
|
|
|
shared_cflag => "-D_WINDLL",
|
|
|
|
shared_ldflag => "-shared",
|
2016-01-30 04:45:29 +00:00
|
|
|
shared_extension => ".dll",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"Cygwin-x86_64" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("x86_64_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => picker(default => "-DTERMIOS -DL_ENDIAN -Wall",
|
|
|
|
debug => "-g -O0",
|
|
|
|
release => "-O3"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "CYGWIN",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "mingw64",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "cygwin-shared",
|
|
|
|
shared_cflag => "-D_WINDLL",
|
|
|
|
shared_ldflag => "-shared",
|
2016-01-30 04:45:29 +00:00
|
|
|
shared_extension => ".dll",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2016-01-17 17:03:04 +00:00
|
|
|
# Backward compatibility for those using this target
|
|
|
|
"Cygwin" => {
|
|
|
|
inherit_from => [ "Cygwin-x86" ]
|
|
|
|
},
|
|
|
|
# In case someone constructs the Cygwin target name themself
|
|
|
|
"Cygwin-i386" => {
|
|
|
|
inherit_from => [ "Cygwin-x86" ]
|
|
|
|
},
|
|
|
|
"Cygwin-i486" => {
|
|
|
|
inherit_from => [ "Cygwin-x86" ]
|
|
|
|
},
|
|
|
|
"Cygwin-i586" => {
|
|
|
|
inherit_from => [ "Cygwin-x86" ]
|
|
|
|
},
|
|
|
|
"Cygwin-i686" => {
|
|
|
|
inherit_from => [ "Cygwin-x86" ]
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### NetWare from David Ward (dsward@novell.com)
|
2015-02-24 22:40:22 +00:00
|
|
|
# requires either MetroWerks NLM development tools, or gcc / nlmconv
|
|
|
|
# NetWare defaults socket bio to WinSock sockets. However,
|
|
|
|
# the builds can be configured to use BSD sockets instead.
|
|
|
|
# netware-clib => legacy CLib c-runtime support
|
2015-03-10 23:58:50 +00:00
|
|
|
"netware-clib" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_Windows" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "mwccnlm",
|
2016-02-27 10:25:33 +00:00
|
|
|
build_scheme => add("netware", { separator => undef }),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"netware-clib-bsdsock" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_Windows" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "mwccnlm",
|
2016-02-27 10:25:33 +00:00
|
|
|
build_scheme => add("netware", { separator => undef }),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"netware-clib-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "i586-netware-gcc",
|
|
|
|
cflags => "-nostdinc -I/ndk/nwsdk/include/nlm -I/ndk/ws295sdk/include -DL_ENDIAN -DNETWARE_CLIB -DOPENSSL_SYS_NETWARE -O2 -Wall",
|
|
|
|
},
|
|
|
|
"netware-clib-bsdsock-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "i586-netware-gcc",
|
|
|
|
cflags => "-nostdinc -I/ndk/nwsdk/include/nlm -DNETWARE_BSDSOCK -DNETDB_USE_INTERNET -DL_ENDIAN -DNETWARE_CLIB -DOPENSSL_SYS_NETWARE -O2 -Wall",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
# netware-libc => LibC/NKS support
|
2015-03-10 23:58:50 +00:00
|
|
|
"netware-libc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_Windows" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "mwccnlm",
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2016-02-27 10:25:33 +00:00
|
|
|
build_scheme => add("netware", { separator => undef }),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"netware-libc-bsdsock" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_Windows" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "mwccnlm",
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2016-02-27 10:25:33 +00:00
|
|
|
build_scheme => add("netware", { separator => undef }),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"netware-libc-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "i586-netware-gcc",
|
|
|
|
cflags => "-nostdinc -I/ndk/libc/include -I/ndk/libc/include/winsock -DL_ENDIAN -DNETWARE_LIBC -DOPENSSL_SYS_NETWARE -DTERMIO -O2 -Wall",
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"netware-libc-bsdsock-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "i586-netware-gcc",
|
|
|
|
cflags => "-nostdinc -I/ndk/libc/include -DNETWARE_BSDSOCK -DL_ENDIAN -DNETWARE_LIBC -DOPENSSL_SYS_NETWARE -DTERMIO -O2 -Wall",
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### DJGPP
|
2015-03-10 23:58:50 +00:00
|
|
|
"DJGPP" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ asm("x86_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
|
|
|
cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIO -DL_ENDIAN -fomit-frame-pointer -O2 -Wall",
|
|
|
|
sys_id => "MSDOS",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-L/dev/env/WATT_ROOT/lib -lwatt"),
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "a.out",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### Ultrix from Bernhard Simon <simon@zid.tuwien.ac.at>
|
2015-03-10 23:58:50 +00:00
|
|
|
"ultrix-cc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
|
|
|
cflags => "-std1 -O -Olimit 2500 -DL_ENDIAN",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"ultrix-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
|
|
|
cflags => "-O3 -DL_ENDIAN",
|
|
|
|
bn_ops => "BN_LLONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "(unknown)",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
# K&R C is no longer supported; you need gcc on old Ultrix installations
|
|
|
|
##"ultrix","cc:-O2 -DNOPROTO -DNOCONST -DL_ENDIAN::(unknown):::::::",
|
|
|
|
|
|
|
|
##### MacOS X (a.k.a. Darwin) setup
|
2015-03-16 21:33:36 +00:00
|
|
|
"darwin-common" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-16 21:33:36 +00:00
|
|
|
template => 1,
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine(picker(default => "",
|
|
|
|
debug => "-g -O0",
|
|
|
|
release => "-O3"),
|
|
|
|
threads("-D_REENTRANT")),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "MACOSX",
|
Enhance and clear the support of linker flags
Some time ago, we had a ex_libs configuration setting that could be
divided into lflags and ex_libs. These got divided in two settings,
lflags and ex_libs, and the former was interpreted to be general
linking flags.
Unfortunately, that conclusion wasn't entirely accurate. Most of
those linking were meant to end up in a very precise position on the
linking command line, just before the spec of libraries the linking
depends on.
Back to the drawing board, we're diving things further, now having
lflags, which are linking flags that aren't depending on command line
position, plib_lflags, which are linking flags that should show up just
before the spec of libraries to depend on, and finally ex_libs, which
is the spec of extra libraries to depend on.
Also, documentation is changed in Configurations/README. This was
previously forgotten.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2016-02-05 10:47:14 +00:00
|
|
|
plib_lflags => "-Wl,-search_paths_first",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "osx32",
|
|
|
|
dso_scheme => "dlfcn",
|
No -fno-common for Darwin
When object files with common block symbols are added to static
libraries on Darwin, those symbols are invisible to the linker that
tries to use them. Our solution was to use -fno-common when compiling
C source.
Unfortunately, there is assembler code that defines OPENSSL_ia32cap_P
as a common block symbol, unconditionally, and in some cases, there is
no other definition. -fno-common doesn't help in this case.
However, 'ranlib -c' adds common block symbols to the index of the
static library, which makes them visible to the linker using it, and
that solves the problem we've seen.
The common conclusion is, either use -fno-common or ranlib -c on
Darwin. Since we have common block symbols unconditionally, choosing
the method for our source is easy.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2016-03-04 12:48:59 +00:00
|
|
|
ranlib => "ranlib -c",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_target => "darwin-shared",
|
No -fno-common for Darwin
When object files with common block symbols are added to static
libraries on Darwin, those symbols are invisible to the linker that
tries to use them. Our solution was to use -fno-common when compiling
C source.
Unfortunately, there is assembler code that defines OPENSSL_ia32cap_P
as a common block symbol, unconditionally, and in some cases, there is
no other definition. -fno-common doesn't help in this case.
However, 'ranlib -c' adds common block symbols to the index of the
static library, which makes them visible to the linker using it, and
that solves the problem we've seen.
The common conclusion is, either use -fno-common or ranlib -c on
Darwin. Since we have common block symbols unconditionally, choosing
the method for our source is easy.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2016-03-04 12:48:59 +00:00
|
|
|
shared_cflag => "-fPIC",
|
2015-03-16 21:33:36 +00:00
|
|
|
shared_ldflag => "-dynamiclib",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_extension => ".\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
"darwin-ppc-cc" => {
|
|
|
|
inherit_from => [ "darwin-common", asm("ppc32_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-arch ppc -DB_ENDIAN -Wa,-force_cpusubtype_ALL"),
|
2015-03-16 21:33:36 +00:00
|
|
|
perlasm_scheme => "osx32",
|
|
|
|
shared_ldflag => "-arch ppc -dynamiclib",
|
|
|
|
},
|
2015-03-10 23:58:50 +00:00
|
|
|
"darwin64-ppc-cc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "darwin-common", asm("ppc64_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-arch ppc64 -DB_ENDIAN"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "osx64",
|
|
|
|
shared_ldflag => "-arch ppc64 -dynamiclib",
|
|
|
|
},
|
|
|
|
"darwin-i386-cc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "darwin-common", asm("x86_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add(picker(default => "-arch i386 -DL_ENDIAN",
|
|
|
|
release => "-fomit-frame-pointer")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_INT",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "macosx",
|
|
|
|
shared_ldflag => "-arch i386 -dynamiclib",
|
|
|
|
},
|
|
|
|
"darwin64-x86_64-cc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "darwin-common", asm("x86_64_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-arch x86_64 -DL_ENDIAN -Wall"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "macosx",
|
|
|
|
shared_ldflag => "-arch x86_64 -dynamiclib",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
|
|
|
#### iPhoneOS/iOS
|
2015-02-24 22:40:22 +00:00
|
|
|
#
|
|
|
|
# It takes three prior-set environment variables to make it work:
|
|
|
|
#
|
|
|
|
# CROSS_COMPILE=/where/toolchain/is/usr/bin/ [note ending slash]
|
|
|
|
# CROSS_TOP=/where/SDKs/are
|
|
|
|
# CROSS_SDK=iPhoneOSx.y.sdk
|
|
|
|
#
|
|
|
|
# Exact paths vary with Xcode releases, but for couple of last ones
|
|
|
|
# they would look like this:
|
|
|
|
#
|
|
|
|
# CROSS_COMPILE=`xcode-select --print-path`/Toolchains/XcodeDefault.xctoolchain/usr/bin/
|
|
|
|
# CROSS_TOP=`xcode-select --print-path`/Platforms/iPhoneOS.platform/Developer
|
2015-03-16 21:33:36 +00:00
|
|
|
# CROSS_SDK=iPhoneOS.sdk
|
2015-02-24 22:40:22 +00:00
|
|
|
#
|
2015-03-10 23:58:50 +00:00
|
|
|
"iphoneos-cross" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "darwin-common" ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK) -fno-common"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "iOS",
|
|
|
|
},
|
2015-04-02 08:17:42 +00:00
|
|
|
"ios-cross" => {
|
|
|
|
inherit_from => [ "darwin-common", asm("armv4_asm") ],
|
|
|
|
# It should be possible to go below iOS 6 and even add -arch armv6,
|
|
|
|
# thus targeting iPhone pre-3GS, but it's assumed to be irrelevant
|
2015-04-21 07:13:27 +00:00
|
|
|
# at this point.
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-arch armv7 -mios-version-min=6.0.0 -isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK) -fno-common"),
|
2015-04-02 08:17:42 +00:00
|
|
|
sys_id => "iOS",
|
|
|
|
perlasm_scheme => "ios32",
|
|
|
|
},
|
2015-03-10 23:58:50 +00:00
|
|
|
"ios64-cross" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "darwin-common", asm("aarch64_asm") ],
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => add("-arch arm64 -mios-version-min=7.0.0 -isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK) -fno-common"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "iOS",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "ios64",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
##### GNU Hurd
|
2015-03-10 23:58:50 +00:00
|
|
|
"hurd-x86" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ asm("x86_elf_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("-DL_ENDIAN -O3 -fomit-frame-pointer -Wall",
|
|
|
|
threads("-pthread")),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-ldl"),
|
2016-01-28 00:16:38 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "linux-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
##### OS/2 EMX
|
2015-03-10 23:58:50 +00:00
|
|
|
"OS2-EMX" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "gcc",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
##### VxWorks for various targets
|
2015-03-10 23:58:50 +00:00
|
|
|
"vxworks-ppc60x" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "ccppc",
|
|
|
|
cflags => "-D_REENTRANT -mrtp -mhard-float -mstrict-align -fno-implicit-fp -DPPC32_fp60x -O2 -fstrength-reduce -fno-builtin -fno-strict-aliasing -Wall -DCPU=PPC32 -DTOOL_FAMILY=gnu -DTOOL=gnu -I\$(WIND_BASE)/target/usr/h -I\$(WIND_BASE)/target/usr/h/wrn/coreip",
|
|
|
|
sys_id => "VXWORKS",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-Wl,--defsym,__wrs_rtp_base=0xe0000000 -L \$(WIND_BASE)/target/usr/lib/ppc/PPC32/common"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"vxworks-ppcgen" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "ccppc",
|
|
|
|
cflags => "-D_REENTRANT -mrtp -msoft-float -mstrict-align -O1 -fno-builtin -fno-strict-aliasing -Wall -DCPU=PPC32 -DTOOL_FAMILY=gnu -DTOOL=gnu -I\$(WIND_BASE)/target/usr/h -I\$(WIND_BASE)/target/usr/h/wrn/coreip",
|
|
|
|
sys_id => "VXWORKS",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-Wl,--defsym,__wrs_rtp_base=0xe0000000 -L \$(WIND_BASE)/target/usr/lib/ppc/PPC32/sfcommon"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"vxworks-ppc405" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "ccppc",
|
|
|
|
cflags => "-g -msoft-float -mlongcall -DCPU=PPC405 -I\$(WIND_BASE)/target/h",
|
|
|
|
sys_id => "VXWORKS",
|
|
|
|
lflags => "-r",
|
|
|
|
},
|
|
|
|
"vxworks-ppc750" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "ccppc",
|
|
|
|
cflags => "-ansi -nostdinc -DPPC750 -D_REENTRANT -fvolatile -fno-builtin -fno-for-scope -fsigned-char -Wall -msoft-float -mlongcall -DCPU=PPC604 -I\$(WIND_BASE)/target/h \$(DEBUG_FLAG)",
|
|
|
|
sys_id => "VXWORKS",
|
|
|
|
lflags => "-r",
|
|
|
|
},
|
|
|
|
"vxworks-ppc750-debug" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "ccppc",
|
2016-01-30 17:04:25 +00:00
|
|
|
cflags => "-ansi -nostdinc -DPPC750 -D_REENTRANT -fvolatile -fno-builtin -fno-for-scope -fsigned-char -Wall -msoft-float -mlongcall -DCPU=PPC604 -I\$(WIND_BASE)/target/h -DBN_DEBUG -DREF_DEBUG -DCONF_DEBUG -DBN_CTX_DEBUG -DPEDANTIC -DDEBUG_SAFESTACK -DDEBUG -g",
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "VXWORKS",
|
|
|
|
lflags => "-r",
|
|
|
|
},
|
|
|
|
"vxworks-ppc860" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "ccppc",
|
|
|
|
cflags => "-nostdinc -msoft-float -DCPU=PPC860 -DNO_STRINGS_H -I\$(WIND_BASE)/target/h",
|
|
|
|
sys_id => "VXWORKS",
|
|
|
|
lflags => "-r",
|
|
|
|
},
|
|
|
|
"vxworks-simlinux" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "ccpentium",
|
|
|
|
cflags => "-B\$(WIND_BASE)/host/\$(WIND_HOST_TYPE)/lib/gcc-lib/ -D_VSB_CONFIG_FILE=\"\$(WIND_BASE)/target/lib/h/config/vsbConfig.h\" -DL_ENDIAN -DCPU=SIMLINUX -DTOOL_FAMILY=gnu -DTOOL=gnu -fno-builtin -fno-defer-pop -DNO_STRINGS_H -I\$(WIND_BASE)/target/h -I\$(WIND_BASE)/target/h/wrn/coreip -DOPENSSL_NO_HW_PADLOCK",
|
|
|
|
sys_id => "VXWORKS",
|
|
|
|
lflags => "-r",
|
|
|
|
ranlib => "ranlibpentium",
|
|
|
|
},
|
|
|
|
"vxworks-mips" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("mips32_asm") ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "ccmips",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("-mrtp -mips2 -O -G 0 -B\$(WIND_BASE)/host/\$(WIND_HOST_TYPE)/lib/gcc-lib/ -D_VSB_CONFIG_FILE=\"\$(WIND_BASE)/target/lib/h/config/vsbConfig.h\" -DCPU=MIPS32 -msoft-float -mno-branch-likely -DTOOL_FAMILY=gnu -DTOOL=gnu -fno-builtin -fno-defer-pop -DNO_STRINGS_H -I\$(WIND_BASE)/target/usr/h -I\$(WIND_BASE)/target/h/wrn/coreip",
|
|
|
|
threads("-D_REENTRANT")),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "VXWORKS",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-Wl,--defsym,__wrs_rtp_base=0xe0000000 -L \$(WIND_BASE)/target/usr/lib/mips/MIPSI32/sfcommon"),
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "o32",
|
|
|
|
ranlib => "ranlibmips",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### uClinux
|
2015-03-10 23:58:50 +00:00
|
|
|
"uClinux-dist" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "$ENV{'CC'}",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("\$(CFLAGS)",
|
|
|
|
threads("-D_REENTRANT")),
|
Enhance and clear the support of linker flags
Some time ago, we had a ex_libs configuration setting that could be
divided into lflags and ex_libs. These got divided in two settings,
lflags and ex_libs, and the former was interpreted to be general
linking flags.
Unfortunately, that conclusion wasn't entirely accurate. Most of
those linking were meant to end up in a very precise position on the
linking command line, just before the spec of libraries the linking
depends on.
Back to the drawing board, we're diving things further, now having
lflags, which are linking flags that aren't depending on command line
position, plib_lflags, which are linking flags that should show up just
before the spec of libraries to depend on, and finally ex_libs, which
is the spec of extra libraries to depend on.
Also, documentation is changed in Configurations/README. This was
previously forgotten.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2016-02-05 10:47:14 +00:00
|
|
|
plib_lflags => "\$(LDFLAGS)",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("\$(LDLIBS)"),
|
2015-03-10 23:58:50 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "$ENV{'LIBSSL_dlfcn'}",
|
|
|
|
shared_target => "linux-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_ldflag => "-shared",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
ranlib => "$ENV{'RANLIB'}",
|
|
|
|
},
|
|
|
|
"uClinux-dist64" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
cc => "$ENV{'CC'}",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("\$(CFLAGS)",
|
|
|
|
threads("-D_REENTRANT")),
|
Enhance and clear the support of linker flags
Some time ago, we had a ex_libs configuration setting that could be
divided into lflags and ex_libs. These got divided in two settings,
lflags and ex_libs, and the former was interpreted to be general
linking flags.
Unfortunately, that conclusion wasn't entirely accurate. Most of
those linking were meant to end up in a very precise position on the
linking command line, just before the spec of libraries the linking
depends on.
Back to the drawing board, we're diving things further, now having
lflags, which are linking flags that aren't depending on command line
position, plib_lflags, which are linking flags that should show up just
before the spec of libraries to depend on, and finally ex_libs, which
is the spec of extra libraries to depend on.
Also, documentation is changed in Configurations/README. This was
previously forgotten.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2016-02-05 10:47:14 +00:00
|
|
|
plib_lflags => "\$(LDFLAGS)",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("\$(LDLIBS)"),
|
2015-03-10 23:58:50 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "$ENV{'LIBSSL_dlfcn'}",
|
|
|
|
shared_target => "linux-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_ldflag => "-shared",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
ranlib => "$ENV{'RANLIB'}",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2016-01-30 06:14:58 +00:00
|
|
|
##### VMS
|
|
|
|
"vms-generic" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_VMS" ],
|
2016-01-30 06:14:58 +00:00
|
|
|
template => 1,
|
|
|
|
cc => "CC/DECC",
|
2016-03-02 18:13:26 +00:00
|
|
|
cflags => picker(default => "/STANDARD=RELAXED/NOLIST/PREFIX=ALL/NAMES=(AS_IS,SHORTENED)",
|
|
|
|
debug => "/NOOPTIMIZE/DEBUG",
|
|
|
|
release => "/OPTIMIZE/NODEBUG"),
|
|
|
|
lflags => picker(default => "/MAP",
|
|
|
|
debug => "/DEBUG/TRACEBACK",
|
|
|
|
release => "/NODEBUG/NOTRACEBACK"),
|
2016-01-30 06:14:58 +00:00
|
|
|
shared_target => "vms-shared",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
thread_scheme => "pthreads",
|
2016-01-30 06:14:58 +00:00
|
|
|
|
2016-02-19 22:55:30 +00:00
|
|
|
apps_aux_src => "vms_decc_init.c",
|
2016-01-30 06:14:58 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
# VMS on VAX is *unsupported*
|
|
|
|
#"vms-asm" => {
|
|
|
|
# template => 1,
|
|
|
|
# bn_obj => "[.asm]vms.obj vms-helper.obj"
|
|
|
|
#},
|
|
|
|
#"vms-vax" => {
|
|
|
|
# inherit_from => [ "vms-generic", asm("vms-asm") ],
|
|
|
|
# as => "MACRO",
|
|
|
|
# debug_aflags => "/NOOPTIMIZE/DEBUG",
|
|
|
|
# release_aflags => "/OPTIMIZE/NODEBUG",
|
|
|
|
# bn_opts => "THIRTY_TWO_BIT RC4_CHAR RC4_CHUNK DES_PTR BF_PTR",
|
|
|
|
#},
|
|
|
|
"vms-alpha" => {
|
|
|
|
inherit_from => [ "vms-generic" ],
|
|
|
|
#as => "???",
|
|
|
|
#debug_aflags => "/NOOPTIMIZE/DEBUG",
|
|
|
|
#release_aflags => "/OPTIMIZE/NODEBUG",
|
|
|
|
bn_opts => "SIXTY_FOUR_BIT RC4_INT RC4_CHUNK_LL DES_PTR BF_PTR",
|
|
|
|
},
|
|
|
|
"vms-alpha-P32" => {
|
|
|
|
inherit_from => [ "vms-alpha" ],
|
2016-02-24 23:17:59 +00:00
|
|
|
cflags => add("/POINTER_SIZE=32"),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => sub { join(",", map { s|SHR([\./])|SHR32$1|g; $_ } @_) },
|
2016-01-30 06:14:58 +00:00
|
|
|
},
|
|
|
|
"vms-alpha-P64" => {
|
|
|
|
inherit_from => [ "vms-alpha" ],
|
2016-02-24 23:17:59 +00:00
|
|
|
cflags => add("/POINTER_SIZE=64"),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => sub { join(",", map { s|SHR([\./])|SHR64$1|g; $_ } @_) },
|
2016-01-30 06:14:58 +00:00
|
|
|
},
|
|
|
|
"vms-ia64" => {
|
|
|
|
inherit_from => [ "vms-generic" ],
|
|
|
|
#as => "I4S",
|
|
|
|
#debug_aflags => "/NOOPTIMIZE/DEBUG",
|
|
|
|
#release_aflags => "/OPTIMIZE/NODEBUG",
|
|
|
|
bn_opts => "SIXTY_FOUR_BIT RC4_INT RC4_CHUNK_LL DES_PTR BF_PTR",
|
|
|
|
},
|
|
|
|
"vms-ia64-P32" => {
|
|
|
|
inherit_from => [ "vms-ia64" ],
|
2016-02-24 23:17:59 +00:00
|
|
|
cflags => add("/POINTER_SIZE=32"),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => sub { join(",", map { s|SHR([\./])|SHR32$1|g; $_ } @_) },
|
2016-01-30 06:14:58 +00:00
|
|
|
},
|
|
|
|
"vms-ia64-P64" => {
|
|
|
|
inherit_from => [ "vms-ia64" ],
|
2016-02-24 23:17:59 +00:00
|
|
|
cflags => add("/POINTER_SIZE=64"),
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => sub { join(",", map { s|SHR([\./])|SHR64$1|g; $_ } @_) },
|
2016-01-30 06:14:58 +00:00
|
|
|
},
|
|
|
|
|
2015-02-24 22:40:22 +00:00
|
|
|
);
|