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 15:12:22 +00:00
|
|
|
# Helper functions for the Windows configs
|
|
|
|
my $vc_win64a_info = {};
|
|
|
|
sub vc_win64a_info {
|
|
|
|
unless (%$vc_win64a_info) {
|
|
|
|
if (`nasm -v 2>NUL` =~ /NASM version ([0-9]+\.[0-9]+)/ && $1 >= 2.0) {
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
$vc_win64a_info = { AS => "nasm",
|
|
|
|
ASFLAGS => "-g",
|
|
|
|
asflags => "-Ox -f win64 -DNEAR",
|
2018-03-07 12:29:04 +00:00
|
|
|
asoutflag => "-o " };
|
2016-04-18 18:15:33 +00:00
|
|
|
} elsif ($disabled{asm}) {
|
2018-03-08 20:11:12 +00:00
|
|
|
# assembler is still used to compile uplink shim
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
$vc_win64a_info = { AS => "ml64",
|
2018-03-09 16:28:06 +00:00
|
|
|
ASFLAGS => "/nologo /Zi",
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
asflags => "/c /Cp /Cx",
|
2016-03-02 15:12:22 +00:00
|
|
|
asoutflag => "/Fo" };
|
2016-04-18 18:15:33 +00:00
|
|
|
} else {
|
2018-07-24 08:45:05 +00:00
|
|
|
$die->("NASM not found - make sure it's installed and available on %PATH%\n");
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
$vc_win64a_info = { AS => "{unknown}",
|
|
|
|
ASFLAGS => "",
|
2016-08-31 17:47:35 +00:00
|
|
|
asflags => "",
|
|
|
|
asoutflag => "" };
|
2016-03-02 15:12:22 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return $vc_win64a_info;
|
|
|
|
}
|
|
|
|
|
2016-04-18 18:15:33 +00:00
|
|
|
my $vc_win32_info = {};
|
|
|
|
sub vc_win32_info {
|
|
|
|
unless (%$vc_win32_info) {
|
|
|
|
my $ver=`nasm -v 2>NUL`;
|
|
|
|
my $vew=`nasmw -v 2>NUL`;
|
|
|
|
if ($ver ne "" || $vew ne "") {
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
$vc_win32_info = { AS => $ver ge $vew ? "nasm" : "nasmw",
|
|
|
|
ASFLAGS => "",
|
2016-04-18 18:15:33 +00:00
|
|
|
asflags => "-f win32",
|
2018-03-07 12:29:04 +00:00
|
|
|
asoutflag => "-o ",
|
2016-04-18 18:15:33 +00:00
|
|
|
perlasm_scheme => "win32n" };
|
|
|
|
} elsif ($disabled{asm}) {
|
2018-03-08 20:11:12 +00:00
|
|
|
# not actually used, uplink shim is inlined into C code
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
$vc_win32_info = { AS => "ml",
|
|
|
|
ASFLAGS => "/nologo /Zi",
|
|
|
|
asflags => "/Cp /coff /c /Cx",
|
2016-04-18 18:15:33 +00:00
|
|
|
asoutflag => "/Fo",
|
|
|
|
perlasm_scheme => "win32" };
|
|
|
|
} else {
|
2018-07-24 08:45:05 +00:00
|
|
|
$die->("NASM not found - make sure it's installed and available on %PATH%\n");
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
$vc_win32_info = { AS => "{unknown}",
|
|
|
|
ASFLAGS => "",
|
2016-08-31 17:47:35 +00:00
|
|
|
asflags => "",
|
|
|
|
asoutflag => "",
|
|
|
|
perlasm_scheme => "win32" };
|
2016-04-18 18:15:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return $vc_win32_info;
|
|
|
|
}
|
|
|
|
|
2016-03-02 15:12:22 +00:00
|
|
|
my $vc_wince_info = {};
|
|
|
|
sub vc_wince_info {
|
|
|
|
unless (%$vc_wince_info) {
|
|
|
|
# sanity check
|
2017-11-29 16:41:10 +00:00
|
|
|
$die->('%OSVERSION% is not defined') if (!defined(env('OSVERSION')));
|
|
|
|
$die->('%PLATFORM% is not defined') if (!defined(env('PLATFORM')));
|
|
|
|
$die->('%TARGETCPU% is not defined') if (!defined(env('TARGETCPU')));
|
2016-03-02 15:12:22 +00:00
|
|
|
|
|
|
|
#
|
|
|
|
# Idea behind this is to mimic flags set by eVC++ IDE...
|
|
|
|
#
|
2017-11-29 16:41:10 +00:00
|
|
|
my $wcevers = env('OSVERSION'); # WCENNN
|
2016-08-31 17:47:35 +00:00
|
|
|
my $wcevernum;
|
|
|
|
my $wceverdotnum;
|
|
|
|
if ($wcevers =~ /^WCE([1-9])([0-9]{2})$/) {
|
|
|
|
$wcevernum = "$1$2";
|
|
|
|
$wceverdotnum = "$1.$2";
|
|
|
|
} else {
|
|
|
|
$die->('%OSVERSION% value is insane');
|
|
|
|
$wcevernum = "{unknown}";
|
|
|
|
$wceverdotnum = "{unknown}";
|
|
|
|
}
|
|
|
|
my $wcecdefs = "-D_WIN32_WCE=$wcevernum -DUNDER_CE=$wcevernum"; # -D_WIN32_WCE=NNN
|
|
|
|
my $wcelflag = "/subsystem:windowsce,$wceverdotnum"; # ...,N.NN
|
2016-03-02 15:12:22 +00:00
|
|
|
|
2017-11-29 16:41:10 +00:00
|
|
|
my $wceplatf = env('PLATFORM');
|
2016-03-14 09:02:13 +00:00
|
|
|
|
|
|
|
$wceplatf =~ tr/a-z0-9 /A-Z0-9_/;
|
|
|
|
$wcecdefs .= " -DWCE_PLATFORM_$wceplatf";
|
2016-03-02 15:12:22 +00:00
|
|
|
|
2017-11-29 16:41:10 +00:00
|
|
|
my $wcetgt = env('TARGETCPU'); # just shorter name...
|
2016-03-02 15:12:22 +00:00
|
|
|
SWITCH: for($wcetgt) {
|
|
|
|
/^X86/ && do { $wcecdefs.=" -Dx86 -D_X86_ -D_i386_ -Di_386_";
|
|
|
|
$wcelflag.=" /machine:X86"; last; };
|
|
|
|
/^ARMV4[IT]/ && do { $wcecdefs.=" -DARM -D_ARM_ -D$wcetgt";
|
|
|
|
$wcecdefs.=" -DTHUMB -D_THUMB_" if($wcetgt=~/T$/);
|
|
|
|
$wcecdefs.=" -QRarch4T -QRinterwork-return";
|
|
|
|
$wcelflag.=" /machine:THUMB"; last; };
|
|
|
|
/^ARM/ && do { $wcecdefs.=" -DARM -D_ARM_ -D$wcetgt";
|
|
|
|
$wcelflag.=" /machine:ARM"; last; };
|
|
|
|
/^MIPSIV/ && do { $wcecdefs.=" -DMIPS -D_MIPS_ -DR4000 -D$wcetgt";
|
|
|
|
$wcecdefs.=" -D_MIPS64 -QMmips4 -QMn32";
|
|
|
|
$wcelflag.=" /machine:MIPSFPU"; last; };
|
|
|
|
/^MIPS16/ && do { $wcecdefs.=" -DMIPS -D_MIPS_ -DR4000 -D$wcetgt";
|
|
|
|
$wcecdefs.=" -DMIPSII -QMmips16";
|
|
|
|
$wcelflag.=" /machine:MIPS16"; last; };
|
|
|
|
/^MIPSII/ && do { $wcecdefs.=" -DMIPS -D_MIPS_ -DR4000 -D$wcetgt";
|
|
|
|
$wcecdefs.=" -QMmips2";
|
|
|
|
$wcelflag.=" /machine:MIPS"; last; };
|
|
|
|
/^R4[0-9]{3}/ && do { $wcecdefs.=" -DMIPS -D_MIPS_ -DR4000";
|
|
|
|
$wcelflag.=" /machine:MIPS"; last; };
|
|
|
|
/^SH[0-9]/ && do { $wcecdefs.=" -D$wcetgt -D_${wcetgt}_ -DSHx";
|
|
|
|
$wcecdefs.=" -Qsh4" if ($wcetgt =~ /^SH4/);
|
|
|
|
$wcelflag.=" /machine:$wcetgt"; last; };
|
|
|
|
{ $wcecdefs.=" -D$wcetgt -D_${wcetgt}_";
|
|
|
|
$wcelflag.=" /machine:$wcetgt"; last; };
|
|
|
|
}
|
|
|
|
|
2018-01-23 12:54:55 +00:00
|
|
|
$vc_wince_info = { cppflags => $wcecdefs,
|
2016-03-02 15:12:22 +00:00
|
|
|
lflags => $wcelflag };
|
|
|
|
}
|
|
|
|
return $vc_wince_info;
|
|
|
|
}
|
|
|
|
|
2016-03-29 18:18:31 +00:00
|
|
|
# Helper functions for the VMS configs
|
|
|
|
my $vms_info = {};
|
|
|
|
sub vms_info {
|
2018-02-14 09:34:12 +00:00
|
|
|
my $pointer_size_str = $config{target} =~ m|-p(\d+)$| ? $1 : "";
|
|
|
|
|
|
|
|
# For the case where Configure iterate through all config targets, such
|
|
|
|
# as when listing them and their details, we reset info if the pointer
|
|
|
|
# size changes.
|
|
|
|
if (%$vms_info && $vms_info->{pointer_size} ne $pointer_size_str) {
|
|
|
|
$vms_info = {};
|
|
|
|
}
|
2016-04-12 14:03:02 +00:00
|
|
|
|
2018-02-14 09:34:12 +00:00
|
|
|
unless (%$vms_info) {
|
2016-04-12 14:03:02 +00:00
|
|
|
$vms_info->{disable_warns} = [ ];
|
2016-07-02 07:50:24 +00:00
|
|
|
$vms_info->{pointer_size} = $pointer_size_str;
|
2018-02-14 09:34:12 +00:00
|
|
|
if ($pointer_size_str eq "64") {
|
2016-04-12 14:03:02 +00:00
|
|
|
`PIPE CC /NOCROSS_REFERENCE /NOLIST /NOOBJECT /WARNINGS = DISABLE = ( MAYLOSEDATA3, EMPTYFILE ) NL: 2> NL:`;
|
|
|
|
if ($? == 0) {
|
|
|
|
push @{$vms_info->{disable_warns}}, "MAYLOSEDATA3";
|
|
|
|
}
|
|
|
|
}
|
2016-04-12 13:28:06 +00:00
|
|
|
|
|
|
|
unless ($disabled{zlib}) {
|
2016-04-12 14:03:02 +00:00
|
|
|
my $default_zlib = 'GNV$LIBZSHR' . $pointer_size_str;
|
2016-04-12 13:28:06 +00:00
|
|
|
if (defined($disabled{"zlib-dynamic"})) {
|
2016-04-12 14:03:02 +00:00
|
|
|
$vms_info->{zlib} = $withargs{zlib_lib} || "$default_zlib/SHARE";
|
2016-04-12 13:28:06 +00:00
|
|
|
} else {
|
2016-04-12 14:03:02 +00:00
|
|
|
$vms_info->{def_zlib} = $withargs{zlib_lib} || $default_zlib;
|
|
|
|
# In case the --with-zlib-lib value contains something like
|
|
|
|
# /SHARE or /LIB or so at the end, remove it.
|
|
|
|
$vms_info->{def_zlib} =~ s|/.*$||g;
|
2016-04-12 13:28:06 +00:00
|
|
|
}
|
|
|
|
}
|
2018-02-13 19:47:34 +00:00
|
|
|
|
|
|
|
if ($config{target} =~ /-ia64/) {
|
|
|
|
`PIPE ias -H 2> NL:`;
|
|
|
|
if ($? == 0) {
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
$vms_info->{AS} = "ias";
|
|
|
|
$vms_info->{ASFLAGS} = '-d debug';
|
|
|
|
$vms_info->{asflags} = '"-N" vms_upcase';
|
2018-03-07 12:29:04 +00:00
|
|
|
$vms_info->{asoutflag} = "-o ";
|
2018-02-13 19:47:34 +00:00
|
|
|
$vms_info->{perlasm_scheme} = "ias";
|
|
|
|
}
|
|
|
|
}
|
2016-03-29 18:18:31 +00:00
|
|
|
}
|
|
|
|
return $vms_info;
|
|
|
|
}
|
2016-03-02 15:12:22 +00:00
|
|
|
|
2017-12-01 14:29:05 +00:00
|
|
|
my %targets = (
|
2015-02-24 22:40:22 +00:00
|
|
|
|
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" => {
|
2018-01-27 12:06:39 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => picker(debug => "-O0 -g",
|
2016-03-02 18:13:26 +00:00
|
|
|
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" => {
|
2018-01-27 12:06:39 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => picker(default => "-Wall",
|
2016-04-06 10:47:35 +00:00
|
|
|
debug => "-O0 -g",
|
2016-03-02 18:13:26 +00:00
|
|
|
release => "-O3"),
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => "-D_POSIX_C_SOURCE=200112L -D_BSD -D_VOS_EXTENDED_NAMES",
|
|
|
|
lib_cppflags => "-DB_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
|
|
|
sys_id => "VOS",
|
2018-01-08 11:28:08 +00:00
|
|
|
lflags => add("-Wl,-map"),
|
2015-03-10 23:58:50 +00:00
|
|
|
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,
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => "-DFILIO_H",
|
2017-03-01 20:40:02 +00:00
|
|
|
ex_libs => add("-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",
|
2018-09-30 12:44:59 +00:00
|
|
|
shared_target => "solaris",
|
2018-06-10 16:06:15 +00:00
|
|
|
shared_ldflag => "-Wl,-Bsymbolic",
|
|
|
|
shared_defflag => "-Wl,-M,",
|
|
|
|
shared_sonameflag=> "-Wl,-h,",
|
2015-11-23 13:12:17 +00:00
|
|
|
},
|
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" => {
|
2016-11-12 15:01:47 +00:00
|
|
|
# NB. GNU C has to be configured to use GNU assembler, and not
|
|
|
|
# /usr/ccs/bin/as. Failure to comply will result in compile
|
|
|
|
# failures [at least] in 32-bit build.
|
2015-11-23 13:12:17 +00:00
|
|
|
inherit_from => [ "solaris-common", asm("x86_elf_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => add_before(picker(default => "-Wall",
|
2016-03-02 18:13:26 +00:00
|
|
|
debug => "-O0 -g",
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
release => "-O3 -fomit-frame-pointer")),
|
|
|
|
cflags => add(threads("-pthread")),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DL_ENDIAN"),
|
2018-01-22 15:50:54 +00:00
|
|
|
ex_libs => add(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",
|
2018-06-13 09:10:27 +00:00
|
|
|
shared_ldflag => add_before("-shared -static-libgcc"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"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:-)
|
2017-10-10 21:55:09 +00:00
|
|
|
# -- <appro@openssl.org>
|
2015-11-23 13:12:17 +00:00
|
|
|
inherit_from => [ "solaris-common", asm("x86_64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => add_before(picker(default => "-Wall",
|
2016-03-02 18:13:26 +00:00
|
|
|
debug => "-O0 -g",
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
release => "-O3")),
|
|
|
|
cflags => add_before("-m64", threads("-pthread")),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DL_ENDIAN"),
|
2018-01-22 15:50:54 +00:00
|
|
|
ex_libs => add(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",
|
2018-06-13 09:10:27 +00:00
|
|
|
shared_ldflag => add_before("-shared -static-libgcc"),
|
2015-03-10 23:58:50 +00:00
|
|
|
multilib => "/64",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
#### Solaris x86 with Sun C setups
|
2016-08-31 14:13:10 +00:00
|
|
|
# There used to be solaris-x86-cc target, but it was removed,
|
|
|
|
# primarily because vendor assembler can't assemble our modules
|
|
|
|
# with -KPIC flag. As result it, assembly support, was not even
|
|
|
|
# available as option. But its lack means lack of side-channel
|
|
|
|
# resistant code, which is incompatible with security by todays
|
|
|
|
# standards. Fortunately gcc is readily available prepackaged
|
|
|
|
# option, which we can firmly point at...
|
|
|
|
#
|
|
|
|
# On related note, solaris64-x86_64-cc target won't compile code
|
|
|
|
# paths utilizing AVX and post-Haswell instruction extensions.
|
|
|
|
# Consider switching to solaris64-x86_64-gcc even here...
|
|
|
|
#
|
2015-03-10 23:58:50 +00:00
|
|
|
"solaris64-x86_64-cc" => {
|
2015-11-23 13:12:17 +00:00
|
|
|
inherit_from => [ "solaris-common", asm("x86_64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => add_before(picker(debug => "-g",
|
2018-01-23 12:54:55 +00:00
|
|
|
release => "-xO5 -xdepend -xbuiltin")),
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
cflags => add_before("-xarch=generic64 -xstrconst -Xa"),
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => add(threads("-D_REENTRANT")),
|
|
|
|
lib_cppflags => add("-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 => "pthreads",
|
2017-12-04 15:31:26 +00:00
|
|
|
lflags => add(threads("-mt")),
|
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
|
|
|
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",
|
2018-06-13 09:10:27 +00:00
|
|
|
shared_ldflag => add_before("-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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => add_before(picker(default => "-Wall",
|
2016-03-02 18:13:26 +00:00
|
|
|
debug => "-O0 -g",
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
release => "-O3")),
|
|
|
|
cflags => add(threads("-pthread")),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DB_ENDIAN -DBN_DIV2W"),
|
2018-01-22 15:50:54 +00:00
|
|
|
ex_libs => add(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",
|
2018-06-13 09:10:27 +00:00
|
|
|
shared_ldflag => add_before("-shared"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"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-04-06 10:47:35 +00:00
|
|
|
cflags => add_before("-m32 -mcpu=ultrasparc"),
|
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
|
|
|
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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => add_before(picker(debug => "-g",
|
2018-01-23 12:54:55 +00:00
|
|
|
release => "-xO5 -xdepend")),
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
cflags => add_before("-xstrconst -Xa"),
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => add(threads("-D_REENTRANT")),
|
|
|
|
lib_cppflags => add("-DB_ENDIAN -DBN_DIV2W"),
|
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
|
|
|
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",
|
2018-06-13 09:10:27 +00:00
|
|
|
shared_ldflag => add_before("-G -dy -z text"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
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-08-30 21:25:10 +00:00
|
|
|
cflags => add_before("-xarch=v8plus"),
|
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-08-30 21:25:10 +00:00
|
|
|
cflags => add_before("-xarch=v9"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
multilib => "/64",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
#### IRIX 6.x configs
|
2016-05-04 21:40:47 +00:00
|
|
|
# Only N32 and N64 ABIs are supported.
|
2018-06-20 12:14:11 +00:00
|
|
|
"irix-common" => {
|
|
|
|
inherit_from => [ "BASE_unix" ],
|
|
|
|
template => 1,
|
|
|
|
cppflags => threads("-D_SGI_MP_SOURCE"),
|
2018-11-12 14:03:39 +00:00
|
|
|
lib_cppflags => "-DB_ENDIAN",
|
2018-06-20 12:14:11 +00:00
|
|
|
ex_libs => add(threads("-lpthread")),
|
|
|
|
thread_scheme => "pthreads",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "self",
|
|
|
|
shared_ldflag => "-shared -Wl,-Bsymbolic",
|
|
|
|
shared_sonameflag=> "-Wl,-soname,",
|
|
|
|
},
|
2015-03-10 23:58:50 +00:00
|
|
|
"irix-mips3-gcc" => {
|
2018-06-20 12:14:11 +00:00
|
|
|
inherit_from => [ "irix-common", asm("mips64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => picker(debug => "-g -O0",
|
|
|
|
release => "-O3"),
|
2018-06-20 12:14:11 +00:00
|
|
|
LDFLAGS => "-static-libgcc",
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
cflags => "-mabi=n32",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "RC4_CHAR SIXTY_FOUR_BIT",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "n32",
|
|
|
|
multilib => "32",
|
|
|
|
},
|
|
|
|
"irix-mips3-cc" => {
|
2018-06-20 12:14:11 +00:00
|
|
|
inherit_from => [ "irix-common", asm("mips64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => picker(debug => "-g -O0",
|
|
|
|
release => "-O2"),
|
|
|
|
cflags => "-n32 -mips3 -use_readonly_const -G0 -rdata_shared",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "RC4_CHAR SIXTY_FOUR_BIT",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "n32",
|
|
|
|
multilib => "32",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
# N64 ABI builds.
|
2015-03-10 23:58:50 +00:00
|
|
|
"irix64-mips4-gcc" => {
|
2018-06-20 12:14:11 +00:00
|
|
|
inherit_from => [ "irix-common", asm("mips64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => picker(debug => "-g -O0",
|
|
|
|
release => "-O3"),
|
2018-06-20 12:14:11 +00:00
|
|
|
LDFLAGS => "-static-libgcc",
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
cflags => "-mabi=64 -mips4",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "RC4_CHAR SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "64",
|
|
|
|
multilib => "64",
|
|
|
|
},
|
|
|
|
"irix64-mips4-cc" => {
|
2018-06-20 12:14:11 +00:00
|
|
|
inherit_from => [ "irix-common", asm("mips64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => picker(debug => "-g -O0",
|
|
|
|
release => "-O2"),
|
|
|
|
cflags => "-64 -mips4 -use_readonly_const -G0 -rdata_shared",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "RC4_CHAR SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "64",
|
|
|
|
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
|
2016-06-26 17:08:51 +00:00
|
|
|
# targets; b) performance-critical 32-bit assembly modules implement
|
|
|
|
# even PA-RISC 2.0-specific code paths, which are chosen at run-time,
|
|
|
|
# thus adequate performance is provided even with PA-RISC 1.1 build.
|
2018-04-08 12:00:03 +00:00
|
|
|
"hpux-common" => {
|
|
|
|
inherit_from => [ "BASE_unix" ],
|
2018-03-24 20:05:05 +00:00
|
|
|
template => 1,
|
|
|
|
defines => add("_XOPEN_SOURCE", "_XOPEN_SOURCE_EXTENDED",
|
|
|
|
"_HPUX_ALT_XOPEN_SOCKET_API"),
|
2018-04-08 12:00:03 +00:00
|
|
|
lib_cppflags => "-DB_ENDIAN",
|
|
|
|
thread_scheme => "pthreads",
|
|
|
|
dso_scheme => "dlfcn", # overridden in 32-bit PA-RISC builds
|
2018-06-13 08:57:51 +00:00
|
|
|
shared_target => "self",
|
|
|
|
bin_lflags => "-Wl,+s,+cdp,../:,+cdp,./:",
|
|
|
|
shared_ldflag => "-Wl,-B,symbolic,+vnocompatwarnings,-z,+s,+cdp,../:,+cdp,./:",
|
|
|
|
shared_sonameflag=> "-Wl,+h,",
|
2018-03-24 20:05:05 +00:00
|
|
|
},
|
2015-03-10 23:58:50 +00:00
|
|
|
"hpux-parisc-gcc" => {
|
2018-04-08 12:00:03 +00:00
|
|
|
inherit_from => [ "hpux-common" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => picker(debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
|
|
|
cflags => add(threads("-pthread")),
|
2018-04-08 12:00:03 +00:00
|
|
|
lib_cppflags => add("-DBN_DIV2W"),
|
2018-03-24 20:05:05 +00:00
|
|
|
ex_libs => add("-ldld", threads("-pthread")),
|
2018-04-08 12:00:03 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dl",
|
|
|
|
shared_cflag => "-fPIC",
|
2018-06-13 08:57:51 +00:00
|
|
|
shared_ldflag => add_before("-shared"),
|
2017-07-19 08:13:41 +00:00
|
|
|
shared_extension => ".sl.\$(SHLIB_VERSION_NUMBER)",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"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" => {
|
2018-04-08 12:00:03 +00:00
|
|
|
inherit_from => [ "hpux-common", asm("parisc20_64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => combine(picker(debug => "-O0 -g",
|
2018-01-23 12:54:55 +00:00
|
|
|
release => "-O3")),
|
2018-03-24 20:05:05 +00:00
|
|
|
cflags => add(threads("-pthread")),
|
|
|
|
ex_libs => add("-ldl", threads("-pthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_cflag => "-fpic",
|
2018-06-13 08:57:51 +00:00
|
|
|
shared_ldflag => add_before("-shared"),
|
2017-07-19 08:13:41 +00:00
|
|
|
shared_extension => ".sl.\$(SHLIB_VERSION_NUMBER)",
|
2015-03-10 23:58:50 +00:00
|
|
|
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.
|
2015-03-10 23:58:50 +00:00
|
|
|
"hpux-parisc-cc" => {
|
2018-04-08 12:00:03 +00:00
|
|
|
inherit_from => [ "hpux-common" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => picker(debug => "+O0 +d -g",
|
|
|
|
release => "+O3"),
|
|
|
|
cflags => "+Optrs_strongly_typed -Ae +ESlit",
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => threads("-D_REENTRANT"),
|
2018-04-08 12:00:03 +00:00
|
|
|
lib_cppflags => add("-DBN_DIV2W -DMD32_XARRAY"),
|
2018-03-24 20:05:05 +00:00
|
|
|
ex_libs => add("-ldld", threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dl",
|
|
|
|
shared_cflag => "+Z",
|
2018-06-13 08:57:51 +00:00
|
|
|
shared_ldflag => add_before("-b"),
|
2017-07-19 08:13:41 +00:00
|
|
|
shared_extension => ".sl.\$(SHLIB_VERSION_NUMBER)",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"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" => {
|
2018-04-08 12:00:03 +00:00
|
|
|
inherit_from => [ "hpux-common", asm("parisc20_64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => picker(debug => "+O0 +d -g",
|
|
|
|
release => "+O3") ,
|
|
|
|
cflags => "+DD64 +Optrs_strongly_typed -Ae +ESlit",
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => threads("-D_REENTRANT") ,
|
2018-04-08 12:00:03 +00:00
|
|
|
lib_cppflags => add("-DMD32_XARRAY"),
|
2018-03-24 20:05:05 +00:00
|
|
|
ex_libs => add("-ldl", threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_cflag => "+Z",
|
2018-06-13 08:57:51 +00:00
|
|
|
shared_ldflag => add_before("-b"),
|
2017-07-19 08:13:41 +00:00
|
|
|
shared_extension => ".sl.\$(SHLIB_VERSION_NUMBER)",
|
2015-03-10 23:58:50 +00:00
|
|
|
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" => {
|
2018-04-08 12:00:03 +00:00
|
|
|
inherit_from => [ "hpux-common", asm("ia64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => picker(debug => "+O0 +d -g",
|
|
|
|
release => "+O2"),
|
|
|
|
cflags => "-Ae +DD32 +Olit=all -z",
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => add(threads("-D_REENTRANT")),
|
2018-03-24 20:05:05 +00:00
|
|
|
ex_libs => add("-ldl", threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_cflag => "+Z",
|
2018-06-13 08:57:51 +00:00
|
|
|
shared_ldflag => add_before("-b"),
|
2015-03-10 23:58:50 +00:00
|
|
|
multilib => "/hpux32",
|
|
|
|
},
|
|
|
|
"hpux64-ia64-cc" => {
|
2018-04-08 12:00:03 +00:00
|
|
|
inherit_from => [ "hpux-common", asm("ia64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => picker(debug => "+O0 +d -g",
|
|
|
|
release => "+O3"),
|
|
|
|
cflags => "-Ae +DD64 +Olit=all -z",
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => threads("-D_REENTRANT"),
|
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
|
|
|
ex_libs => add("-ldl", threads("-lpthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_cflag => "+Z",
|
2018-06-13 08:57:51 +00:00
|
|
|
shared_ldflag => add_before("-b"),
|
2015-03-10 23:58:50 +00:00
|
|
|
multilib => "/hpux64",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
# GCC builds...
|
2015-03-10 23:58:50 +00:00
|
|
|
"hpux-ia64-gcc" => {
|
2018-04-08 12:00:03 +00:00
|
|
|
inherit_from => [ "hpux-common", asm("ia64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => picker(debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
|
|
|
cflags => add(threads("-pthread")),
|
2018-01-22 15:50:54 +00:00
|
|
|
ex_libs => add("-ldl", threads("-pthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_cflag => "-fpic",
|
2018-06-13 08:57:51 +00:00
|
|
|
shared_ldflag => add_before("-shared"),
|
2015-03-10 23:58:50 +00:00
|
|
|
multilib => "/hpux32",
|
|
|
|
},
|
|
|
|
"hpux64-ia64-gcc" => {
|
2018-04-08 12:00:03 +00:00
|
|
|
inherit_from => [ "hpux-common", asm("ia64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => picker(debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
|
|
|
cflags => combine("-mlp64", threads("-pthread")),
|
2018-01-22 15:50:54 +00:00
|
|
|
ex_libs => add("-ldl", threads("-pthread")),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_cflag => "-fpic",
|
2018-06-13 08:57:51 +00:00
|
|
|
shared_ldflag => add_before("-shared"),
|
2015-03-10 23:58:50 +00:00
|
|
|
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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => "-O3",
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => "-D_POSIX_SOURCE -D_SOCKET_SOURCE",
|
|
|
|
includes => [ "/SYSLOG/PUB" ],
|
|
|
|
lib_cppflags => "-DBN_DIV2W",
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "MPE",
|
2018-01-08 11:28:08 +00:00
|
|
|
lflags => add("-L/SYSLOG/PUB"),
|
|
|
|
ex_libs => add("-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
|
|
|
|
2016-05-02 08:33:42 +00:00
|
|
|
#### DEC Alpha Tru64 targets. Tru64 is marketing name for OSF/1 version 4
|
|
|
|
#### and forward. In reality 'uname -s' still returns "OSF1". Originally
|
|
|
|
#### there were even osf1-* configs targeting prior versions provided,
|
|
|
|
#### but not anymore...
|
|
|
|
"tru64-alpha-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("alpha_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => "-O3",
|
|
|
|
cflags => add("-std=c9x", threads("-pthread")),
|
2018-01-23 12:54:55 +00:00
|
|
|
cppflags => "-D_XOPEN_SOURCE=500 -D_OSF_SOURCE",
|
2018-01-22 15:50:54 +00:00
|
|
|
ex_libs => add("-lrt", threads("-pthread")), # for mlock(2)
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
2016-05-02 08:33:42 +00:00
|
|
|
thread_scheme => "pthreads",
|
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") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => "-tune host -fast",
|
|
|
|
cflags => add("-std1 -readonly_strings",
|
|
|
|
threads("-pthread")),
|
2018-01-23 12:54:55 +00:00
|
|
|
cppflags => "-D_XOPEN_SOURCE=500 -D_OSF_SOURCE",
|
2018-01-22 15:50:54 +00:00
|
|
|
ex_libs => add("-lrt", threads("-pthread")), # for mlock(2)
|
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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CXX => "g++",
|
|
|
|
CFLAGS => picker(default => "-Wall",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
|
|
|
CXXFLAGS => picker(default => "-Wall",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
|
|
|
cflags => threads("-pthread"),
|
|
|
|
cxxflags => combine("-std=c++11", threads("-pthread")),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => "-DOPENSSL_USE_NODELETE",
|
2018-01-22 15:50:54 +00:00
|
|
|
ex_libs => add("-ldl", threads("-pthread")),
|
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",
|
2018-01-23 12:54:55 +00:00
|
|
|
shared_cflag => "-fPIC",
|
2018-11-16 14:05:14 +00:00
|
|
|
shared_ldflag => sub { $disabled{pinshared} ? () : "-Wl,-znodelete" },
|
2018-01-25 21:50:55 +00:00
|
|
|
enable => [ "afalgeng" ],
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
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") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-m64"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-m64"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DB_ENDIAN"),
|
2015-03-16 21:33:36 +00:00
|
|
|
perlasm_scheme => "linux64",
|
|
|
|
multilib => "64",
|
|
|
|
},
|
|
|
|
"linux-ppc64le" => {
|
|
|
|
inherit_from => [ "linux-generic64", asm("ppc64_asm") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-m64"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-m64"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DL_ENDIAN"),
|
2015-03-16 21:33:36 +00:00
|
|
|
perlasm_scheme => "linux64le",
|
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"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => 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",
|
|
|
|
},
|
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") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-mabi=32"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-mabi=32"),
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "o32",
|
|
|
|
},
|
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") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-mabi=n32"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-mabi=n32"),
|
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",
|
|
|
|
multilib => "32",
|
|
|
|
},
|
|
|
|
"linux64-mips64" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "linux-generic64", asm("mips64_asm") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-mabi=64"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-mabi=64"),
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "64",
|
|
|
|
multilib => "64",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
|
|
|
#### IA-32 targets...
|
2016-11-15 08:53:01 +00:00
|
|
|
#### These two targets are a bit aged and are to be used on older Linux
|
|
|
|
#### machines where gcc doesn't understand -m32 and -m64
|
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") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CFLAGS => add(picker(release => "-fomit-frame-pointer")),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DL_ENDIAN"),
|
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") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => add(picker(default => "-Wall",
|
2016-03-02 18:13:26 +00:00
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O3 -fomit-frame-pointer")),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DL_ENDIAN"),
|
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
|
|
|
|
2016-11-15 08:53:01 +00:00
|
|
|
#### X86 / X86_64 targets
|
|
|
|
"linux-x86" => {
|
|
|
|
inherit_from => [ "linux-generic32", asm("x86_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CFLAGS => add(picker(release => "-fomit-frame-pointer")),
|
|
|
|
cflags => add("-m32"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-m32"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DL_ENDIAN"),
|
2016-11-15 08:53:01 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
|
|
|
perlasm_scheme => "elf",
|
|
|
|
},
|
|
|
|
"linux-x86-clang" => {
|
|
|
|
inherit_from => [ "linux-x86" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "clang",
|
|
|
|
CXX => "clang++",
|
2016-11-15 08:53:01 +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") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-m64"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-m64"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => 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
|
|
|
perlasm_scheme => "elf",
|
|
|
|
multilib => "64",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
"linux-x86_64-clang" => {
|
|
|
|
inherit_from => [ "linux-x86_64" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "clang",
|
|
|
|
CXX => "clang++",
|
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") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-mx32"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-mx32"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DL_ENDIAN"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT",
|
2016-03-15 22:39:07 +00:00
|
|
|
perlasm_scheme => "elf32",
|
2015-03-10 23:58:50 +00:00
|
|
|
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") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-m64"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-m64"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DB_ENDIAN"),
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "64",
|
|
|
|
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") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-m31 -Wa,-mzarch"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-m31 -Wa,-mzarch"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DB_ENDIAN"),
|
2016-03-11 15:47:02 +00:00
|
|
|
bn_asm_src => sub { my $r=join(" ",@_); $r=~s|asm/s390x\.S|bn_asm.c|; $r; },
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "31",
|
|
|
|
multilib => "/highgprs",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
|
|
|
#### SPARC Linux setups
|
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") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-mcpu=v8"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-mcpu=v8"),
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
lib_cppflags => add("-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") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-m32 -mcpu=ultrasparc -Wa,-Av8plus"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-m32 -mcpu=ultrasparc -Wa,-Av8plus"),
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
lib_cppflags => add("-DB_ENDIAN -DBN_DIV2W"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"linux64-sparcv9" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
# GCC 3.1 is a requirement
|
|
|
|
inherit_from => [ "linux-generic64", asm("sparcv9_asm") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-m64 -mcpu=ultrasparc"),
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => add("-m64 -mcpu=ultrasparc"),
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
lib_cppflags => add("-DB_ENDIAN"),
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
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") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
lib_cppflags => 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
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cl6x",
|
|
|
|
CFLAGS => "-o2 -ox -ms",
|
|
|
|
cflags => "--linux -ea=.s -eo=.o -mv6400+ -pden",
|
2018-03-07 12:29:41 +00:00
|
|
|
cxxflags => "--linux -ea=.s -eo=.o -mv6400+ -pden",
|
2018-01-23 12:54:55 +00:00
|
|
|
cppflags => combine("-DOPENSSL_SMALL_FOOTPRINT",
|
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
|
|
|
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",
|
2016-10-18 14:11:57 +00:00
|
|
|
shared_ldflag => add("-z --sysv --shared"),
|
2015-03-10 23:58:50 +00:00
|
|
|
ranlib => "true",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => picker(default => "-Wall",
|
|
|
|
debug => "-O0 -g",
|
|
|
|
release => "-O3"),
|
|
|
|
cflags => threads("-pthread"),
|
2018-01-23 12:54:55 +00:00
|
|
|
cppflags => threads("-D_THREAD_SAFE -D_REENTRANT"),
|
2018-01-22 15:50:54 +00:00
|
|
|
ex_libs => add(threads("-pthread")),
|
2017-03-24 15:19:00 +00:00
|
|
|
enable => add("devcryptoeng"),
|
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",
|
|
|
|
},
|
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") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CFLAGS => add(picker(release => "-fomit-frame-pointer")),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DL_ENDIAN"),
|
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") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-mcpu=v8"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-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") ],
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => 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") ],
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => 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
|
|
|
},
|
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") ],
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => 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
|
|
|
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") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => "-fomit-frame-pointer -O3 -Wall",
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => "-DPERL5 -DL_ENDIAN",
|
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",
|
|
|
|
},
|
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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => "-O -Wall",
|
2015-03-10 23:58:50 +00:00
|
|
|
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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => "-O3 -Wall",
|
2015-03-10 23:58:50 +00:00
|
|
|
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
|
|
|
|
|
|
|
#### 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
|
2017-10-10 21:55:09 +00:00
|
|
|
# compiler drivers and assemblers.
|
2015-02-24 22:40:22 +00:00
|
|
|
#
|
|
|
|
# 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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
cflags => threads("-Kthread"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => "-DFILIO_H -DNO_STRINGS_H",
|
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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => "-O",
|
|
|
|
cflags => threads("-Kthread"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => "-DFILIO_H",
|
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") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => "-O",
|
|
|
|
cflags => combine("-Kalloca", threads("-Kthread")),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => "-DFILIO_H",
|
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",
|
|
|
|
},
|
|
|
|
"unixware-7-gcc" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("x86_elf_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => "-O3 -fomit-frame-pointer -Wall",
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => add(threads("-D_REENTRANT")),
|
|
|
|
lib_cppflags => add("-DL_ENDIAN -DFILIO_H"),
|
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",
|
|
|
|
},
|
2017-10-10 21:55:09 +00:00
|
|
|
# SCO 5 - Ben Laurie 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",
|
|
|
|
},
|
|
|
|
"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",
|
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
|
|
|
#### IBM's AIX.
|
2016-09-03 20:03:55 +00:00
|
|
|
# Below targets assume AIX >=5. Caveat lector. If you are accustomed
|
|
|
|
# to control compilation "bitness" by setting $OBJECT_MODE environment
|
|
|
|
# variable, then you should know that in OpenSSL case it's considered
|
|
|
|
# only in ./config. Once configured, build procedure remains "deaf" to
|
|
|
|
# current value of $OBJECT_MODE.
|
2018-06-11 10:43:50 +00:00
|
|
|
"aix-common" => {
|
|
|
|
inherit_from => [ "BASE_unix" ],
|
|
|
|
template => 1,
|
|
|
|
sys_id => "AIX",
|
|
|
|
lib_cppflags => "-DB_ENDIAN",
|
2018-06-15 13:24:14 +00:00
|
|
|
lflags => "-Wl,-bsvr4",
|
2018-06-11 10:43:50 +00:00
|
|
|
thread_scheme => "pthreads",
|
|
|
|
dso_scheme => "dlfcn",
|
2018-09-30 12:44:59 +00:00
|
|
|
shared_target => "aix",
|
2018-06-15 13:24:14 +00:00
|
|
|
module_ldflags => "-Wl,-G,-bsymbolic,-bexpall",
|
2019-02-19 12:22:35 +00:00
|
|
|
shared_ldflag => "-Wl,-G,-bsymbolic,-bnoentry",
|
2018-06-11 10:50:25 +00:00
|
|
|
shared_defflag => "-Wl,-bE:",
|
2019-02-04 20:28:43 +00:00
|
|
|
perl_platform => 'AIX',
|
2018-06-11 10:43:50 +00:00
|
|
|
},
|
2015-03-10 23:58:50 +00:00
|
|
|
"aix-gcc" => {
|
2018-06-11 10:43:50 +00:00
|
|
|
inherit_from => [ "aix-common", asm("ppc32_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => picker(debug => "-O0 -g",
|
|
|
|
release => "-O"),
|
|
|
|
cflags => add(threads("-pthread")),
|
2018-06-11 10:43:50 +00:00
|
|
|
ex_libs => threads("-pthread"),
|
2015-03-10 23:58:50 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
|
|
|
perlasm_scheme => "aix32",
|
2018-06-13 09:10:27 +00:00
|
|
|
shared_ldflag => add_before("-shared -static-libgcc"),
|
2018-03-21 19:04:49 +00:00
|
|
|
AR => add("-X32"),
|
|
|
|
RANLIB => add("-X32"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"aix64-gcc" => {
|
2018-06-11 10:43:50 +00:00
|
|
|
inherit_from => [ "aix-common", asm("ppc64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => picker(debug => "-O0 -g",
|
|
|
|
release => "-O"),
|
|
|
|
cflags => combine("-maix64", threads("-pthread")),
|
2018-06-11 10:43:50 +00:00
|
|
|
ex_libs => threads("-pthread"),
|
2015-03-10 23:58:50 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHAR",
|
|
|
|
perlasm_scheme => "aix64",
|
2018-06-13 09:10:27 +00:00
|
|
|
shared_ldflag => add_before("-shared -static-libgcc"),
|
2018-06-14 09:45:15 +00:00
|
|
|
shared_extension => "64.so.\$(SHLIB_VERSION_NUMBER)",
|
2018-03-21 19:04:49 +00:00
|
|
|
AR => add("-X64"),
|
|
|
|
RANLIB => add("-X64"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"aix-cc" => {
|
2018-06-11 10:43:50 +00:00
|
|
|
inherit_from => [ "aix-common", asm("ppc32_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => picker(debug => "-O0 -g",
|
|
|
|
release => "-O"),
|
|
|
|
cflags => combine("-q32 -qmaxmem=16384 -qro -qroconst",
|
2018-01-23 12:54:55 +00:00
|
|
|
threads("-qthreaded")),
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => threads("-D_THREAD_SAFE"),
|
2016-09-03 20:03:55 +00:00
|
|
|
ex_libs => threads("-lpthreads"),
|
2018-06-11 10:43:50 +00:00
|
|
|
bn_ops => "BN_LLONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "aix32",
|
2018-03-19 17:37:46 +00:00
|
|
|
shared_cflag => "-qpic",
|
2018-03-21 19:04:49 +00:00
|
|
|
AR => add("-X32"),
|
|
|
|
RANLIB => add("-X32"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"aix64-cc" => {
|
2018-06-11 10:43:50 +00:00
|
|
|
inherit_from => [ "aix-common", asm("ppc64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => picker(debug => "-O0 -g",
|
|
|
|
release => "-O"),
|
|
|
|
cflags => combine("-q64 -qmaxmem=16384 -qro -qroconst",
|
2018-01-23 12:54:55 +00:00
|
|
|
threads("-qthreaded")),
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => threads("-D_THREAD_SAFE"),
|
2016-09-03 20:03:55 +00:00
|
|
|
ex_libs => threads("-lpthreads"),
|
2018-06-11 10:43:50 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHAR",
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "aix64",
|
|
|
|
dso_scheme => "dlfcn",
|
2018-03-19 17:37:46 +00:00
|
|
|
shared_cflag => "-qpic",
|
2018-06-14 09:45:15 +00:00
|
|
|
shared_extension => "64.so.\$(SHLIB_VERSION_NUMBER)",
|
2018-03-21 19:04:49 +00:00
|
|
|
AR => add("-X64"),
|
|
|
|
RANLIB => add("-X64"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "c89",
|
|
|
|
CFLAGS => "-O",
|
|
|
|
cflags => "-XLLML -XLLMK -XL",
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => "-DCHARSET_EBCDIC",
|
|
|
|
lib_cppflags => "-DB_ENDIAN",
|
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
|
|
|
|
2015-03-16 21:33:36 +00:00
|
|
|
#### Visual C targets
|
2015-02-24 22:40:22 +00:00
|
|
|
#
|
2018-03-09 16:28:06 +00:00
|
|
|
# Win64 targets, WIN64I denotes IA-64/Itanium and WIN64A - AMD64
|
2015-02-24 22:40:22 +00:00
|
|
|
#
|
2018-03-09 16:28:06 +00:00
|
|
|
# Note about /wd4090, disable warning C4090. This warning returns false
|
2015-02-24 22:40:22 +00:00
|
|
|
# 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.
|
2016-03-02 15:12:22 +00:00
|
|
|
#
|
|
|
|
# Also note that we force threads no matter what. Configuring "no-threads"
|
|
|
|
# is ignored.
|
2018-03-09 16:28:06 +00:00
|
|
|
#
|
|
|
|
# UNICODE is defined in VC-common and applies to all targets. It used to
|
|
|
|
# be an opt-in option for VC-WIN32, but not anymore. The original reason
|
|
|
|
# was because ANSI API was *native* system interface for no longer
|
|
|
|
# supported Windows 9x. Keep in mind that UNICODE only affects how
|
|
|
|
# OpenSSL libraries interact with underlying OS, it doesn't affect API
|
|
|
|
# that OpenSSL presents to application.
|
|
|
|
|
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,
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cl",
|
|
|
|
CPP => '$(CC) /EP /C',
|
2018-03-09 16:28:06 +00:00
|
|
|
CFLAGS => "/W3 /wd4090 /nologo",
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
LDFLAGS => add("/debug"),
|
|
|
|
coutflag => "/Fo",
|
2018-01-23 12:54:55 +00:00
|
|
|
defines => add("OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
|
2018-03-09 16:28:06 +00:00
|
|
|
"UNICODE", "_UNICODE",
|
2018-03-06 20:09:05 +00:00
|
|
|
"_CRT_SECURE_NO_DEPRECATE",
|
|
|
|
"_WINSOCK_DEPRECATED_NO_WARNINGS"),
|
2018-03-09 16:28:06 +00:00
|
|
|
lib_cflags => add("/Zi /Fdossl_static.pdb"),
|
|
|
|
lib_defines => add("L_ENDIAN"),
|
|
|
|
dso_cflags => "/Zi /Fddso.pdb",
|
|
|
|
bin_cflags => "/Zi /Fdapp.pdb",
|
2018-09-30 12:44:59 +00:00
|
|
|
# def_flag made to empty string so a .def file gets generated
|
|
|
|
shared_defflag => '',
|
2016-03-02 15:12:22 +00:00
|
|
|
shared_ldflag => "/dll",
|
2016-03-02 13:10:21 +00:00
|
|
|
shared_target => "win-shared", # meaningless except it gives Configure a hint
|
2016-03-02 15:12:22 +00:00
|
|
|
thread_scheme => "winthreads",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "win32",
|
2016-07-16 21:21:39 +00:00
|
|
|
apps_aux_src => add("win32_init.c"),
|
2018-03-09 16:28:06 +00:00
|
|
|
bn_ops => "EXPORT_VAR_AS_FN",
|
2018-10-23 12:36:23 +00:00
|
|
|
perl_platform => 'Windows::MSVC',
|
2018-03-03 21:26:45 +00:00
|
|
|
# additional parameter to build_scheme denotes install-path "flavour"
|
|
|
|
build_scheme => add("VC-common", { separator => undef }),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2016-03-02 15:12:22 +00:00
|
|
|
"VC-noCE-common" => {
|
2016-03-18 22:31:17 +00:00
|
|
|
inherit_from => [ "VC-common" ],
|
2016-10-31 15:40:36 +00:00
|
|
|
template => 1,
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CFLAGS => add(picker(debug => '/Od',
|
|
|
|
release => '/O2')),
|
2018-03-09 16:28:06 +00:00
|
|
|
cflags => add(picker(default => '/Gs0 /GF /Gy',
|
|
|
|
debug =>
|
2016-03-02 15:12:22 +00:00
|
|
|
sub {
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
($disabled{shared} ? "" : "/MDd");
|
2016-03-02 15:12:22 +00:00
|
|
|
},
|
|
|
|
release =>
|
|
|
|
sub {
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
($disabled{shared} ? "" : "/MD");
|
2016-03-02 15:12:22 +00:00
|
|
|
})),
|
2018-03-28 08:07:32 +00:00
|
|
|
defines => add(picker(default => [], # works as type cast
|
|
|
|
debug => [ "DEBUG", "_DEBUG" ])),
|
2016-04-06 15:33:03 +00:00
|
|
|
lib_cflags => add(sub { $disabled{shared} ? "/MT /Zl" : () }),
|
|
|
|
# Following might/should appears controversial, i.e. defining
|
|
|
|
# /MDd without evaluating $disabled{shared}. It works in
|
|
|
|
# non-shared build because static library is compiled with /Zl
|
|
|
|
# and bares no reference to specific RTL. And it works in
|
|
|
|
# shared build because multiple /MDd options are not prohibited.
|
|
|
|
# But why /MDd in static build? Well, basically this is just a
|
|
|
|
# reference point, which allows to catch eventual errors that
|
|
|
|
# would prevent those who want to wrap OpenSSL into own .DLL.
|
|
|
|
# Why not /MD in release build then? Well, some are likely to
|
|
|
|
# prefer [non-debug] openssl.exe to be free from Micorosoft RTL
|
|
|
|
# redistributable.
|
|
|
|
bin_cflags => add(picker(debug => "/MDd",
|
|
|
|
release => sub { $disabled{shared} ? "/MT" : () },
|
|
|
|
)),
|
2016-03-02 15:12:22 +00:00
|
|
|
bin_lflags => add("/subsystem:console /opt:ref"),
|
2016-04-15 05:53:17 +00:00
|
|
|
ex_libs => add(sub {
|
2016-03-02 15:12:22 +00:00
|
|
|
my @ex_libs = ();
|
|
|
|
push @ex_libs, 'ws2_32.lib' unless $disabled{sock};
|
|
|
|
push @ex_libs, 'gdi32.lib advapi32.lib crypt32.lib user32.lib';
|
|
|
|
return join(" ", @ex_libs);
|
2016-04-15 05:53:17 +00:00
|
|
|
}),
|
2016-03-02 15:12:22 +00:00
|
|
|
},
|
|
|
|
"VC-WIN64-common" => {
|
|
|
|
inherit_from => [ "VC-noCE-common" ],
|
2016-10-31 15:40:36 +00:00
|
|
|
template => 1,
|
2016-04-15 05:53:17 +00:00
|
|
|
ex_libs => add(sub {
|
2016-03-02 15:12:22 +00:00
|
|
|
my @ex_libs = ();
|
|
|
|
push @ex_libs, 'bufferoverflowu.lib' if (`cl 2>&1` =~ /14\.00\.4[0-9]{4}\./);
|
|
|
|
return join(" ", @_, @ex_libs);
|
2016-04-15 05:53:17 +00:00
|
|
|
}),
|
2018-03-09 16:28:06 +00:00
|
|
|
bn_ops => add("SIXTY_FOUR_BIT"),
|
2016-03-02 15:12:22 +00:00
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
"VC-WIN64I" => {
|
2016-03-18 22:31:17 +00:00
|
|
|
inherit_from => [ "VC-WIN64-common", asm("ia64_asm"),
|
|
|
|
sub { $disabled{shared} ? () : "ia64_uplink" } ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
AS => "ias",
|
|
|
|
ASFLAGS => "-d debug",
|
2018-03-09 16:28:06 +00:00
|
|
|
asoutflag => "-o ",
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "WIN64I",
|
2016-03-23 19:33:29 +00:00
|
|
|
bn_asm_src => sub { return undef unless @_;
|
|
|
|
my $r=join(" ",@_); $r=~s|bn-ia64.s|bn_asm.c|; $r; },
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "ias",
|
2016-03-23 19:33:29 +00:00
|
|
|
multilib => "-ia64",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"VC-WIN64A" => {
|
2016-03-18 22:31:17 +00:00
|
|
|
inherit_from => [ "VC-WIN64-common", asm("x86_64_asm"),
|
|
|
|
sub { $disabled{shared} ? () : "x86_64_uplink" } ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
AS => sub { vc_win64a_info()->{AS} },
|
|
|
|
ASFLAGS => sub { vc_win64a_info()->{ASFLAGS} },
|
2016-03-02 15:12:22 +00:00
|
|
|
asoutflag => sub { vc_win64a_info()->{asoutflag} },
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
asflags => sub { vc_win64a_info()->{asflags} },
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "WIN64A",
|
2016-03-02 15:12:22 +00:00
|
|
|
bn_asm_src => sub { return undef unless @_;
|
|
|
|
my $r=join(" ",@_); $r=~s|asm/x86_64-gcc|bn_asm|; $r; },
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "auto",
|
2016-03-23 19:33:29 +00:00
|
|
|
multilib => "-x64",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"VC-WIN32" => {
|
2016-03-18 22:31:17 +00:00
|
|
|
inherit_from => [ "VC-noCE-common", asm("x86_asm"),
|
2016-03-23 20:04:22 +00:00
|
|
|
sub { $disabled{shared} ? () : "uplink_common" } ],
|
2018-03-09 16:28:06 +00:00
|
|
|
CFLAGS => add("/WX"),
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
AS => sub { vc_win32_info()->{AS} },
|
|
|
|
ASFLAGS => sub { vc_win32_info()->{ASFLAGS} },
|
2016-04-18 18:15:33 +00:00
|
|
|
asoutflag => sub { vc_win32_info()->{asoutflag} },
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
asflags => sub { vc_win32_info()->{asflags} },
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "WIN32",
|
2018-03-09 16:28:06 +00:00
|
|
|
bn_ops => add("BN_LLONG"),
|
2016-04-19 21:22:55 +00:00
|
|
|
perlasm_scheme => sub { vc_win32_info()->{perlasm_scheme} },
|
2018-03-03 21:26:45 +00:00
|
|
|
# "WOW" stands for "Windows on Windows", and "VC-WOW" engages
|
|
|
|
# some installation path heuristics in windows-makefile.tmpl...
|
|
|
|
build_scheme => add("VC-WOW", { separator => undef }),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"VC-CE" => {
|
2016-03-02 15:12:22 +00:00
|
|
|
inherit_from => [ "VC-common" ],
|
2018-03-09 16:28:06 +00:00
|
|
|
CFLAGS => add(picker(debug => "/Od",
|
|
|
|
release => "/O1i")),
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CPPDEFINES => picker(debug => [ "DEBUG", "_DEBUG" ]),
|
|
|
|
LDFLAGS => add("/nologo /opt:ref"),
|
2016-03-02 15:12:22 +00:00
|
|
|
cflags =>
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
combine('/GF /Gy',
|
|
|
|
sub { vc_wince_info()->{cflags}; },
|
|
|
|
sub { `cl 2>&1` =~ /Version ([0-9]+)\./ && $1>=14
|
|
|
|
? ($disabled{shared} ? " /MT" : " /MD")
|
|
|
|
: " /MC"; }),
|
2018-01-28 12:26:01 +00:00
|
|
|
cppflags => sub { vc_wince_info()->{cppflags}; },
|
2018-03-09 16:28:06 +00:00
|
|
|
lib_defines => add("NO_CHMOD", "OPENSSL_SMALL_FOOTPRINT"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => sub { vc_wince_info()->{cppflags}; },
|
2018-01-23 12:54:55 +00:00
|
|
|
includes =>
|
2018-02-08 22:26:22 +00:00
|
|
|
add(combine(sub { defined(env('WCECOMPAT'))
|
|
|
|
? '$(WCECOMPAT)/include' : (); },
|
|
|
|
sub { defined(env('PORTSDK_LIBPATH'))
|
|
|
|
? '$(PORTSDK_LIBPATH)/../../include'
|
|
|
|
: (); })),
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
lflags => add(combine(sub { vc_wince_info()->{lflags}; },
|
2018-01-08 11:28:08 +00:00
|
|
|
sub { defined(env('PORTSDK_LIBPATH'))
|
|
|
|
? "/entry:mainCRTstartup" : (); })),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "WINCE",
|
2018-03-09 16:28:06 +00:00
|
|
|
bn_ops => add("BN_LLONG"),
|
2016-04-15 05:53:17 +00:00
|
|
|
ex_libs => add(sub {
|
2016-03-02 15:12:22 +00:00
|
|
|
my @ex_libs = ();
|
|
|
|
push @ex_libs, 'ws2.lib' unless $disabled{sock};
|
|
|
|
push @ex_libs, 'crypt32.lib';
|
2017-11-29 16:41:10 +00:00
|
|
|
if (defined(env('WCECOMPAT'))) {
|
2016-03-02 15:12:22 +00:00
|
|
|
my $x = '$(WCECOMPAT)/lib';
|
2017-11-29 16:41:10 +00:00
|
|
|
if (-f "$x/env('TARGETCPU')/wcecompatex.lib") {
|
2016-03-02 15:12:22 +00:00
|
|
|
$x .= '/$(TARGETCPU)/wcecompatex.lib';
|
|
|
|
} else {
|
|
|
|
$x .= '/wcecompatex.lib';
|
|
|
|
}
|
|
|
|
push @ex_libs, $x;
|
|
|
|
}
|
|
|
|
push @ex_libs, '$(PORTSDK_LIBPATH)/portlib.lib'
|
2017-11-29 16:41:10 +00:00
|
|
|
if (defined(env('PORTSDK_LIBPATH')));
|
2016-03-02 15:12:22 +00:00
|
|
|
push @ex_libs, ' /nodefaultlib coredll.lib corelibc.lib'
|
2017-11-29 16:41:10 +00:00
|
|
|
if (env('TARGETCPU') eq "X86");
|
2016-03-02 15:12:22 +00:00
|
|
|
return @ex_libs;
|
2016-04-15 05:53:17 +00:00
|
|
|
}),
|
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
|
Rework building: Unix changes to handle extensions and product names
Add platform::Unix, which is a generic Unix module to support product
name and extensions functionlity. However, this isn't quite enough,
as mingw and Cygwin builds are done using the same templates, but
since shared libraries work as on Windows and are named accordingly,
platform::mingw and platform::Cygwin were also added to provide the
necessary tweaks.
This reworks Configurations/unix-Makefile.tmpl to work out product
names in platform::Unix et al terms. In this one, we currently do
care about the *_extension config attributes, and the modules adapt
accordingly where it matters.
This change also affected crypto/include/internal/dso_conf.h.in, since
the DSO extension is meant to be the same as the short shared library
extension, which isn't '.so' everywhere.
'shared_extension' attributes that had the value
'.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides
an extension where the shared library version number is hard-coded
instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
2018-10-23 13:09:57 +00:00
|
|
|
"mingw-common" => {
|
|
|
|
inherit_from => [ 'BASE_unix' ],
|
|
|
|
template => 1,
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => picker(default => "-Wall",
|
2018-01-23 12:54:55 +00:00
|
|
|
debug => "-g -O0",
|
Rework building: Unix changes to handle extensions and product names
Add platform::Unix, which is a generic Unix module to support product
name and extensions functionlity. However, this isn't quite enough,
as mingw and Cygwin builds are done using the same templates, but
since shared libraries work as on Windows and are named accordingly,
platform::mingw and platform::Cygwin were also added to provide the
necessary tweaks.
This reworks Configurations/unix-Makefile.tmpl to work out product
names in platform::Unix et al terms. In this one, we currently do
care about the *_extension config attributes, and the modules adapt
accordingly where it matters.
This change also affected crypto/include/internal/dso_conf.h.in, since
the DSO extension is meant to be the same as the short shared library
extension, which isn't '.so' everywhere.
'shared_extension' attributes that had the value
'.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides
an extension where the shared library version number is hard-coded
instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
2018-10-23 13:09:57 +00:00
|
|
|
release => "-O3"),
|
2018-03-06 20:09:05 +00:00
|
|
|
cppflags => combine("-DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN",
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
threads("-D_MT")),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => "-DL_ENDIAN",
|
2016-02-27 10:37:33 +00:00
|
|
|
ex_libs => add("-lws2_32 -lgdi32 -lcrypt32"),
|
Rework building: Unix changes to handle extensions and product names
Add platform::Unix, which is a generic Unix module to support product
name and extensions functionlity. However, this isn't quite enough,
as mingw and Cygwin builds are done using the same templates, but
since shared libraries work as on Windows and are named accordingly,
platform::mingw and platform::Cygwin were also added to provide the
necessary tweaks.
This reworks Configurations/unix-Makefile.tmpl to work out product
names in platform::Unix et al terms. In this one, we currently do
care about the *_extension config attributes, and the modules adapt
accordingly where it matters.
This change also affected crypto/include/internal/dso_conf.h.in, since
the DSO extension is meant to be the same as the short shared library
extension, which isn't '.so' everywhere.
'shared_extension' attributes that had the value
'.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides
an extension where the shared library version number is hard-coded
instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
2018-10-23 13:09:57 +00:00
|
|
|
bn_ops => "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
|
|
|
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",
|
2018-01-23 12:54:55 +00:00
|
|
|
shared_cppflags => add("_WINDLL"),
|
2016-02-05 14:14:45 +00:00
|
|
|
shared_ldflag => "-static-libgcc",
|
Rework building: Unix changes to handle extensions and product names
Add platform::Unix, which is a generic Unix module to support product
name and extensions functionlity. However, this isn't quite enough,
as mingw and Cygwin builds are done using the same templates, but
since shared libraries work as on Windows and are named accordingly,
platform::mingw and platform::Cygwin were also added to provide the
necessary tweaks.
This reworks Configurations/unix-Makefile.tmpl to work out product
names in platform::Unix et al terms. In this one, we currently do
care about the *_extension config attributes, and the modules adapt
accordingly where it matters.
This change also affected crypto/include/internal/dso_conf.h.in, since
the DSO extension is meant to be the same as the short shared library
extension, which isn't '.so' everywhere.
'shared_extension' attributes that had the value
'.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides
an extension where the shared library version number is hard-coded
instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
2018-10-23 13:09:57 +00:00
|
|
|
apps_aux_src => add("win32_init.c"),
|
|
|
|
|
|
|
|
perl_platform => 'mingw',
|
|
|
|
},
|
|
|
|
"mingw" => {
|
|
|
|
inherit_from => [ "mingw-common", asm("x86_asm"),
|
|
|
|
sub { $disabled{shared} ? () : "x86_uplink" } ],
|
|
|
|
CFLAGS => add(picker(release => "-fomit-frame-pointer")),
|
|
|
|
cflags => "-m32",
|
|
|
|
sys_id => "MINGW32",
|
|
|
|
bn_ops => add("BN_LLONG"),
|
|
|
|
perlasm_scheme => "coff",
|
2016-02-05 14:17:33 +00:00
|
|
|
shared_rcflag => "--target=pe-i386",
|
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.
|
Rework building: Unix changes to handle extensions and product names
Add platform::Unix, which is a generic Unix module to support product
name and extensions functionlity. However, this isn't quite enough,
as mingw and Cygwin builds are done using the same templates, but
since shared libraries work as on Windows and are named accordingly,
platform::mingw and platform::Cygwin were also added to provide the
necessary tweaks.
This reworks Configurations/unix-Makefile.tmpl to work out product
names in platform::Unix et al terms. In this one, we currently do
care about the *_extension config attributes, and the modules adapt
accordingly where it matters.
This change also affected crypto/include/internal/dso_conf.h.in, since
the DSO extension is meant to be the same as the short shared library
extension, which isn't '.so' everywhere.
'shared_extension' attributes that had the value
'.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides
an extension where the shared library version number is hard-coded
instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
2018-10-23 13:09:57 +00:00
|
|
|
inherit_from => [ "mingw-common", asm("x86_64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
cflags => "-m64",
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "MINGW64",
|
Rework building: Unix changes to handle extensions and product names
Add platform::Unix, which is a generic Unix module to support product
name and extensions functionlity. However, this isn't quite enough,
as mingw and Cygwin builds are done using the same templates, but
since shared libraries work as on Windows and are named accordingly,
platform::mingw and platform::Cygwin were also added to provide the
necessary tweaks.
This reworks Configurations/unix-Makefile.tmpl to work out product
names in platform::Unix et al terms. In this one, we currently do
care about the *_extension config attributes, and the modules adapt
accordingly where it matters.
This change also affected crypto/include/internal/dso_conf.h.in, since
the DSO extension is meant to be the same as the short shared library
extension, which isn't '.so' everywhere.
'shared_extension' attributes that had the value
'.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides
an extension where the shared library version number is hard-coded
instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
2018-10-23 13:09:57 +00:00
|
|
|
bn_ops => add("SIXTY_FOUR_BIT"),
|
2015-03-10 23:58:50 +00:00
|
|
|
perlasm_scheme => "mingw64",
|
2016-02-05 14:17:33 +00:00
|
|
|
shared_rcflag => "--target=pe-x86-64",
|
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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => "-O",
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => "-DL_ENDIAN",
|
2015-09-09 02:51:17 +00:00
|
|
|
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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => "-O -Wall",
|
|
|
|
lib_cppflags => "-DTERMIOS -DL_ENDIAN",
|
2015-03-10 23:58:50 +00:00
|
|
|
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
|
Rework building: Unix changes to handle extensions and product names
Add platform::Unix, which is a generic Unix module to support product
name and extensions functionlity. However, this isn't quite enough,
as mingw and Cygwin builds are done using the same templates, but
since shared libraries work as on Windows and are named accordingly,
platform::mingw and platform::Cygwin were also added to provide the
necessary tweaks.
This reworks Configurations/unix-Makefile.tmpl to work out product
names in platform::Unix et al terms. In this one, we currently do
care about the *_extension config attributes, and the modules adapt
accordingly where it matters.
This change also affected crypto/include/internal/dso_conf.h.in, since
the DSO extension is meant to be the same as the short shared library
extension, which isn't '.so' everywhere.
'shared_extension' attributes that had the value
'.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides
an extension where the shared library version number is hard-coded
instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
2018-10-23 13:09:57 +00:00
|
|
|
"Cygwin-common" => {
|
2019-04-05 13:38:09 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
Rework building: Unix changes to handle extensions and product names
Add platform::Unix, which is a generic Unix module to support product
name and extensions functionlity. However, this isn't quite enough,
as mingw and Cygwin builds are done using the same templates, but
since shared libraries work as on Windows and are named accordingly,
platform::mingw and platform::Cygwin were also added to provide the
necessary tweaks.
This reworks Configurations/unix-Makefile.tmpl to work out product
names in platform::Unix et al terms. In this one, we currently do
care about the *_extension config attributes, and the modules adapt
accordingly where it matters.
This change also affected crypto/include/internal/dso_conf.h.in, since
the DSO extension is meant to be the same as the short shared library
extension, which isn't '.so' everywhere.
'shared_extension' attributes that had the value
'.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides
an extension where the shared library version number is hard-coded
instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
2018-10-23 13:09:57 +00:00
|
|
|
template => 1,
|
|
|
|
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => picker(default => "-Wall",
|
2016-03-02 18:13:26 +00:00
|
|
|
debug => "-g -O0",
|
Rework building: Unix changes to handle extensions and product names
Add platform::Unix, which is a generic Unix module to support product
name and extensions functionlity. However, this isn't quite enough,
as mingw and Cygwin builds are done using the same templates, but
since shared libraries work as on Windows and are named accordingly,
platform::mingw and platform::Cygwin were also added to provide the
necessary tweaks.
This reworks Configurations/unix-Makefile.tmpl to work out product
names in platform::Unix et al terms. In this one, we currently do
care about the *_extension config attributes, and the modules adapt
accordingly where it matters.
This change also affected crypto/include/internal/dso_conf.h.in, since
the DSO extension is meant to be the same as the short shared library
extension, which isn't '.so' everywhere.
'shared_extension' attributes that had the value
'.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides
an extension where the shared library version number is hard-coded
instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
2018-10-23 13:09:57 +00:00
|
|
|
release => "-O3"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => "-DTERMIOS -DL_ENDIAN",
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "CYGWIN",
|
2016-03-15 14:30:43 +00:00
|
|
|
thread_scheme => "pthread",
|
2015-03-10 23:58:50 +00:00
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "cygwin-shared",
|
2018-01-23 12:54:55 +00:00
|
|
|
shared_cppflags => "-D_WINDLL",
|
Rework building: Unix changes to handle extensions and product names
Add platform::Unix, which is a generic Unix module to support product
name and extensions functionlity. However, this isn't quite enough,
as mingw and Cygwin builds are done using the same templates, but
since shared libraries work as on Windows and are named accordingly,
platform::mingw and platform::Cygwin were also added to provide the
necessary tweaks.
This reworks Configurations/unix-Makefile.tmpl to work out product
names in platform::Unix et al terms. In this one, we currently do
care about the *_extension config attributes, and the modules adapt
accordingly where it matters.
This change also affected crypto/include/internal/dso_conf.h.in, since
the DSO extension is meant to be the same as the short shared library
extension, which isn't '.so' everywhere.
'shared_extension' attributes that had the value
'.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides
an extension where the shared library version number is hard-coded
instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
2018-10-23 13:09:57 +00:00
|
|
|
|
|
|
|
perl_platform => 'Cygwin',
|
|
|
|
},
|
|
|
|
"Cygwin-x86" => {
|
|
|
|
inherit_from => [ "Cygwin-common", asm("x86_asm") ],
|
|
|
|
CFLAGS => add(picker(release => "-O3 -fomit-frame-pointer")),
|
|
|
|
bn_ops => "BN_LLONG",
|
|
|
|
perlasm_scheme => "coff",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"Cygwin-x86_64" => {
|
Rework building: Unix changes to handle extensions and product names
Add platform::Unix, which is a generic Unix module to support product
name and extensions functionlity. However, this isn't quite enough,
as mingw and Cygwin builds are done using the same templates, but
since shared libraries work as on Windows and are named accordingly,
platform::mingw and platform::Cygwin were also added to provide the
necessary tweaks.
This reworks Configurations/unix-Makefile.tmpl to work out product
names in platform::Unix et al terms. In this one, we currently do
care about the *_extension config attributes, and the modules adapt
accordingly where it matters.
This change also affected crypto/include/internal/dso_conf.h.in, since
the DSO extension is meant to be the same as the short shared library
extension, which isn't '.so' everywhere.
'shared_extension' attributes that had the value
'.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides
an extension where the shared library version number is hard-coded
instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
2018-10-23 13:09:57 +00:00
|
|
|
inherit_from => [ "Cygwin-common", asm("x86_64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
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",
|
|
|
|
},
|
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
|
|
|
|
|
|
|
##### 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,
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
CFLAGS => picker(debug => "-g -O0",
|
2018-01-23 12:54:55 +00:00
|
|
|
release => "-O3"),
|
|
|
|
cppflags => threads("-D_REENTRANT"),
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
lflags => "-Wl,-search_paths_first",
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "MACOSX",
|
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",
|
2017-07-19 08:13:41 +00:00
|
|
|
shared_extension => ".\$(SHLIB_VERSION_NUMBER).dylib",
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2016-03-14 19:56:44 +00:00
|
|
|
# Option "freeze" such as -std=gnu9x can't negatively interfere
|
|
|
|
# with future defaults for below two targets, because MacOS X
|
|
|
|
# for PPC has no future, it was discontinued by vendor in 2009.
|
2015-03-16 21:33:36 +00:00
|
|
|
"darwin-ppc-cc" => {
|
|
|
|
inherit_from => [ "darwin-common", asm("ppc32_asm") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-arch ppc -std=gnu9x -Wa,-force_cpusubtype_ALL"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DB_ENDIAN"),
|
2018-03-05 15:55:48 +00:00
|
|
|
shared_cflag => add("-fno-common"),
|
2015-03-16 21:33:36 +00:00
|
|
|
perlasm_scheme => "osx32",
|
|
|
|
},
|
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") ],
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => add("-arch ppc64 -std=gnu9x"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-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",
|
|
|
|
},
|
|
|
|
"darwin-i386-cc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "darwin-common", asm("x86_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CFLAGS => add(picker(release => "-fomit-frame-pointer")),
|
|
|
|
cflags => add("-arch i386"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => add("-DL_ENDIAN"),
|
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",
|
|
|
|
},
|
|
|
|
"darwin64-x86_64-cc" => {
|
2015-03-16 21:33:36 +00:00
|
|
|
inherit_from => [ "darwin-common", asm("x86_64_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CFLAGS => add("-Wall"),
|
|
|
|
cflags => add("-arch x86_64"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => 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
|
|
|
perlasm_scheme => "macosx",
|
|
|
|
},
|
2015-03-16 21:33:36 +00:00
|
|
|
|
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") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "gcc",
|
|
|
|
CFLAGS => "-O3 -fomit-frame-pointer -Wall",
|
|
|
|
cflags => threads("-pthread"),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_cppflags => "-DL_ENDIAN",
|
2018-01-22 15:50:54 +00:00
|
|
|
ex_libs => add("-ldl", threads("-pthread")),
|
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
|
|
|
|
|
|
|
##### 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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "ccppc",
|
|
|
|
CFLAGS => "-O2 -Wall -fstrength-reduce",
|
|
|
|
cflags => "-mrtp -mhard-float -mstrict-align -fno-implicit-fp -fno-builtin -fno-strict-aliasing",
|
2018-01-23 12:54:55 +00:00
|
|
|
cppflags => combine("-D_REENTRANT -DPPC32_fp60x -DCPU=PPC32",
|
|
|
|
"_DTOOL_FAMILY=gnu -DTOOL=gnu",
|
|
|
|
"-I\$(WIND_BASE)/target/usr/h",
|
|
|
|
"-I\$(WIND_BASE)/target/usr/h/wrn/coreip"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "VXWORKS",
|
2018-01-08 11:28:08 +00:00
|
|
|
lflags => add("-L \$(WIND_BASE)/target/usr/lib/ppc/PPC32/common"),
|
|
|
|
ex_libs => add("-Wl,--defsym,__wrs_rtp_base=0xe0000000"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"vxworks-ppcgen" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "ccppc",
|
|
|
|
CFLAGS => "-O1 -Wall",
|
|
|
|
cflags => "-mrtp -msoft-float -mstrict-align -fno-builtin -fno-strict-aliasing",
|
2018-01-23 12:54:55 +00:00
|
|
|
cppflags => combine("-D_REENTRANT -DPPC32 -DCPU=PPC32",
|
|
|
|
"-DTOOL_FAMILY=gnu -DTOOL=gnu",
|
|
|
|
"-I\$(WIND_BASE)/target/usr/h",
|
|
|
|
"-I\$(WIND_BASE)/target/usr/h/wrn/coreip"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "VXWORKS",
|
2018-01-08 11:28:08 +00:00
|
|
|
lflags => add("-L \$(WIND_BASE)/target/usr/lib/ppc/PPC32/sfcommon"),
|
|
|
|
ex_libs => add("-Wl,--defsym,__wrs_rtp_base=0xe0000000"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"vxworks-ppc405" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "ccppc",
|
|
|
|
CFLAGS => "-g",
|
|
|
|
cflags => "-msoft-float -mlongcall",
|
2018-01-23 12:54:55 +00:00
|
|
|
cppflags => combine("-D_REENTRANT -DPPC32 -DCPU=PPC405",
|
|
|
|
"-DTOOL_FAMILY=gnu -DTOOL=gnu",
|
|
|
|
"-I\$(WIND_BASE)/target/h"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "VXWORKS",
|
2018-01-08 11:28:08 +00:00
|
|
|
lflags => add("-r"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"vxworks-ppc750" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "ccppc",
|
|
|
|
CFLAGS => "-ansi -fvolatile -Wall \$(DEBUG_FLAG)",
|
|
|
|
cflags => "-nostdinc -fno-builtin -fno-for-scope -fsigned-char -msoft-float -mlongcall",
|
2018-01-23 12:54:55 +00:00
|
|
|
cppflags => combine("-DPPC750 -D_REENTRANT -DCPU=PPC604",
|
|
|
|
"-I\$(WIND_BASE)/target/h"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "VXWORKS",
|
2018-01-08 11:28:08 +00:00
|
|
|
lflags => add("-r"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"vxworks-ppc750-debug" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "ccppc",
|
|
|
|
CFLAGS => "-ansi -fvolatile -Wall -g",
|
|
|
|
cflags => "-nostdinc -fno-builtin -fno-for-scope -fsigned-char -msoft-float -mlongcall",
|
2018-01-23 12:54:55 +00:00
|
|
|
cppflags => combine("-DPPC750 -D_REENTRANT -DCPU=PPC604",
|
|
|
|
"-DPEDANTIC -DDEBUG",
|
|
|
|
"-I\$(WIND_BASE)/target/h"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "VXWORKS",
|
2018-01-08 11:28:08 +00:00
|
|
|
lflags => add("-r"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"vxworks-ppc860" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "ccppc",
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => "-nostdinc -msoft-float",
|
|
|
|
cppflags => combine("-DCPU=PPC860 -DNO_STRINGS_H",
|
|
|
|
"-I\$(WIND_BASE)/target/h"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "VXWORKS",
|
2018-01-08 11:28:08 +00:00
|
|
|
lflags => add("-r"),
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"vxworks-simlinux" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "ccpentium",
|
2018-01-23 12:54:55 +00:00
|
|
|
cflags => "-B\$(WIND_BASE)/host/\$(WIND_HOST_TYPE)/lib/gcc-lib/ -fno-builtin -fno-defer-pop",
|
|
|
|
cppflags => combine("-D_VSB_CONFIG_FILE=\"\$(WIND_BASE)/target/lib/h/config/vsbConfig.h\"",
|
|
|
|
"-DL_ENDIAN -DCPU=SIMLINUX -DNO_STRINGS_H",
|
|
|
|
"-DTOOL_FAMILY=gnu -DTOOL=gnu",
|
|
|
|
"-DOPENSSL_NO_HW_PADLOCK",
|
|
|
|
"-I\$(WIND_BASE)/target/h",
|
|
|
|
"-I\$(WIND_BASE)/target/h/wrn/coreip"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "VXWORKS",
|
2018-01-08 11:28:08 +00:00
|
|
|
lflags => add("-r"),
|
2015-03-10 23:58:50 +00:00
|
|
|
ranlib => "ranlibpentium",
|
|
|
|
},
|
|
|
|
"vxworks-mips" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix", asm("mips32_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "ccmips",
|
|
|
|
CFLAGS => "-O -G 0",
|
|
|
|
cflags => "-mrtp -mips2 -B\$(WIND_BASE)/host/\$(WIND_HOST_TYPE)/lib/gcc-lib/ -msoft-float -mno-branch-likely -fno-builtin -fno-defer-pop",
|
2018-01-23 12:54:55 +00:00
|
|
|
cppflags => combine("-D_VSB_CONFIG_FILE=\"\$(WIND_BASE)/target/lib/h/config/vsbConfig.h\"",
|
|
|
|
"-DCPU=MIPS32 -DNO_STRINGS_H",
|
|
|
|
"-DTOOL_FAMILY=gnu -DTOOL=gnu",
|
|
|
|
"-DOPENSSL_NO_HW_PADLOCK",
|
|
|
|
threads("-D_REENTRANT"),
|
|
|
|
"-I\$(WIND_BASE)/target/h",
|
|
|
|
"-I\$(WIND_BASE)/target/h/wrn/coreip"),
|
2015-03-10 23:58:50 +00:00
|
|
|
sys_id => "VXWORKS",
|
2018-01-08 11:28:08 +00:00
|
|
|
lflags => add("-L \$(WIND_BASE)/target/usr/lib/mips/MIPSI32/sfcommon"),
|
|
|
|
ex_libs => add("-Wl,--defsym,__wrs_rtp_base=0xe0000000"),
|
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" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => sub { env('CC') },
|
2018-01-23 12:54:55 +00:00
|
|
|
cppflags => threads("-D_REENTRANT"),
|
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",
|
2017-11-29 16:41:10 +00:00
|
|
|
dso_scheme => sub { env('LIBSSL_dlfcn') },
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_target => "linux-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
2017-11-29 16:41:10 +00:00
|
|
|
ranlib => sub { env('RANLIB') },
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
|
|
|
"uClinux-dist64" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_unix" ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => sub { env('CC') },
|
2018-01-23 12:54:55 +00:00
|
|
|
cppflags => threads("-D_REENTRANT"),
|
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",
|
2017-11-29 16:41:10 +00:00
|
|
|
dso_scheme => sub { env('LIBSSL_dlfcn') },
|
2015-03-10 23:58:50 +00:00
|
|
|
shared_target => "linux-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
2017-11-29 16:41:10 +00:00
|
|
|
ranlib => sub { env('RANLIB') },
|
2015-03-10 23:58:50 +00:00
|
|
|
},
|
2015-02-24 22:40:22 +00:00
|
|
|
|
2016-01-30 06:14:58 +00:00
|
|
|
##### VMS
|
2018-02-14 09:34:12 +00:00
|
|
|
# Most things happen in vms-generic.
|
|
|
|
# Note that vms_info extracts the pointer size from the end of
|
|
|
|
# the target name, and will assume that anything matching /-p\d+$/
|
|
|
|
# indicates the pointer size setting for the desired target.
|
2016-01-30 06:14:58 +00:00
|
|
|
"vms-generic" => {
|
2016-02-27 10:25:33 +00:00
|
|
|
inherit_from => [ "BASE_VMS" ],
|
2016-01-30 06:14:58 +00:00
|
|
|
template => 1,
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "CC/DECC",
|
|
|
|
CPP => '$(CC)/PREPROCESS_ONLY=SYS$OUTPUT:',
|
|
|
|
CFLAGS =>
|
2018-02-14 09:34:12 +00:00
|
|
|
combine(picker(default => "/STANDARD=(ISOC94,RELAXED)/NOLIST/PREFIX=ALL",
|
|
|
|
debug => "/NOOPTIMIZE/DEBUG",
|
|
|
|
release => "/OPTIMIZE/NODEBUG"),
|
|
|
|
sub { my @warnings =
|
|
|
|
@{vms_info()->{disable_warns}};
|
|
|
|
@warnings
|
|
|
|
? "/WARNINGS=DISABLE=(".join(",",@warnings).")" : (); }),
|
2018-03-06 20:09:05 +00:00
|
|
|
lib_defines =>
|
2018-02-14 09:34:12 +00:00
|
|
|
add("OPENSSL_USE_NODELETE",
|
|
|
|
sub {
|
|
|
|
return vms_info()->{def_zlib}
|
|
|
|
? "LIBZ=\"\"\"".vms_info()->{def_zlib}."\"\"\"" : ();
|
|
|
|
}),
|
2017-03-14 21:00:13 +00:00
|
|
|
lflags => picker(default => "/MAP='F\$PARSE(\".MAP\",\"\$\@\")'",
|
2017-03-15 01:52:20 +00:00
|
|
|
debug => "/DEBUG/TRACEBACK",
|
2016-03-02 18:13:26 +00:00
|
|
|
release => "/NODEBUG/NOTRACEBACK"),
|
2018-09-13 15:02:53 +00:00
|
|
|
# Because of dso_cflags below, we can't set the generic |cflags| here,
|
|
|
|
# as it can't be overriden, so we set separate C flags for libraries
|
|
|
|
# and binaries instead.
|
|
|
|
bin_cflags => add("/NAMES=(AS_IS,SHORTENED)/EXTERN_MODEL=STRICT_REFDEF"),
|
2016-08-21 21:36:49 +00:00
|
|
|
lib_cflags => add("/NAMES=(AS_IS,SHORTENED)/EXTERN_MODEL=STRICT_REFDEF"),
|
2018-09-13 15:02:53 +00:00
|
|
|
# For modules specifically, we assume that they only use public
|
|
|
|
# OpenSSL symbols, and therefore don't need to mangle names on
|
|
|
|
# their own.
|
|
|
|
dso_cflags => "",
|
2018-02-14 09:34:12 +00:00
|
|
|
ex_libs => add(sub { return vms_info()->{zlib} || (); }),
|
2016-01-30 06:14:58 +00:00
|
|
|
shared_target => "vms-shared",
|
2018-09-30 12:44:59 +00:00
|
|
|
# def_flag made to empty string so a .opt file gets generated
|
|
|
|
shared_defflag => '',
|
2016-03-23 07:40:56 +00:00
|
|
|
dso_scheme => "vms",
|
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
|
|
|
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
AS => sub { vms_info()->{AS} },
|
|
|
|
ASFLAGS => sub { vms_info()->{ASFLAGS} },
|
2018-02-13 19:47:34 +00:00
|
|
|
asoutflag => sub { vms_info()->{asoutflag} },
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
asflags => sub { vms_info()->{asflags} },
|
2018-02-13 19:47:34 +00:00
|
|
|
perlasm_scheme => sub { vms_info()->{perlasm_scheme} },
|
|
|
|
|
2019-01-31 13:23:22 +00:00
|
|
|
disable => add('pinshared'),
|
|
|
|
|
2019-03-03 09:20:37 +00:00
|
|
|
apps_aux_src => "vms_term_sock.c vms_decc_argv.c",
|
2018-01-31 13:15:52 +00:00
|
|
|
apps_init_src => "vms_decc_init.c",
|
2016-01-30 06:14:58 +00:00
|
|
|
},
|
|
|
|
|
2018-02-14 09:34:12 +00:00
|
|
|
# From HELP CC/POINTER_SIZE:
|
|
|
|
#
|
|
|
|
# ----------
|
|
|
|
# LONG[=ARGV] The compiler assumes 64-bit pointers. If the ARGV option to
|
|
|
|
# LONG or 64 is present, the main argument argv will be an
|
|
|
|
# array of long pointers instead of an array of short pointers.
|
|
|
|
#
|
|
|
|
# 64[=ARGV] Same as LONG.
|
|
|
|
# ----------
|
|
|
|
#
|
|
|
|
# We don't want the hassle of dealing with 32-bit pointers with argv, so
|
|
|
|
# we force it to have 64-bit pointers, see the added cflags in the -p64
|
|
|
|
# config targets below.
|
|
|
|
|
2016-01-30 06:14:58 +00:00
|
|
|
"vms-alpha" => {
|
|
|
|
inherit_from => [ "vms-generic" ],
|
2018-02-14 09:34:12 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT RC4_INT",
|
|
|
|
pointer_size => "",
|
2016-01-30 06:14:58 +00:00
|
|
|
},
|
2016-03-21 19:20:15 +00:00
|
|
|
"vms-alpha-p32" => {
|
2018-02-14 09:34:12 +00:00
|
|
|
inherit_from => [ "vms-alpha" ],
|
|
|
|
cflags => add("/POINTER_SIZE=32"),
|
|
|
|
pointer_size => "32",
|
2016-01-30 06:14:58 +00:00
|
|
|
},
|
2016-03-21 19:20:15 +00:00
|
|
|
"vms-alpha-p64" => {
|
2018-02-14 09:34:12 +00:00
|
|
|
inherit_from => [ "vms-alpha" ],
|
|
|
|
cflags => add("/POINTER_SIZE=64=ARGV"),
|
|
|
|
pointer_size => "64",
|
2016-01-30 06:14:58 +00:00
|
|
|
},
|
|
|
|
"vms-ia64" => {
|
2018-02-13 19:51:07 +00:00
|
|
|
inherit_from => [ "vms-generic",
|
2018-11-24 10:37:10 +00:00
|
|
|
sub { vms_info()->{AS}
|
2018-02-13 19:51:07 +00:00
|
|
|
? asm("ia64_asm")->() : () } ],
|
2018-02-14 09:34:12 +00:00
|
|
|
bn_ops => "SIXTY_FOUR_BIT RC4_INT",
|
|
|
|
pointer_size => "",
|
2018-02-13 19:51:07 +00:00
|
|
|
|
|
|
|
modes_asm_src => "", # Because ghash-ia64.s doesn't work on VMS
|
2016-01-30 06:14:58 +00:00
|
|
|
},
|
2016-03-21 19:20:15 +00:00
|
|
|
"vms-ia64-p32" => {
|
2018-02-14 09:34:12 +00:00
|
|
|
inherit_from => [ "vms-ia64" ],
|
|
|
|
cflags => add("/POINTER_SIZE=32"),
|
|
|
|
pointer_size => "32",
|
2016-01-30 06:14:58 +00:00
|
|
|
},
|
2016-03-21 19:20:15 +00:00
|
|
|
"vms-ia64-p64" => {
|
2018-02-14 09:34:12 +00:00
|
|
|
inherit_from => [ "vms-ia64" ],
|
|
|
|
cflags => add("/POINTER_SIZE=64=ARGV"),
|
|
|
|
pointer_size => "64",
|
2016-01-30 06:14:58 +00:00
|
|
|
},
|
|
|
|
|
2015-02-24 22:40:22 +00:00
|
|
|
);
|