2015-11-24 05:44:58 +00:00
|
|
|
## -*- mode: perl; -*-
|
2015-03-12 13:58:07 +00:00
|
|
|
## Personal configuration targets
|
|
|
|
|
|
|
|
%targets = (
|
|
|
|
"debug-ben" => {
|
|
|
|
cc => "gcc",
|
2016-01-30 17:04:25 +00:00
|
|
|
cflags => "$gcc_devteam_warn -DBN_DEBUG -DREF_DEBUG -DCONF_DEBUG -DBN_CTX_DEBUG -DDEBUG_SAFESTACK -O2 -pipe",
|
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-12 13:58:07 +00:00
|
|
|
},
|
|
|
|
"debug-ben-openbsd" => {
|
|
|
|
cc => "gcc",
|
2016-01-30 17:04:25 +00:00
|
|
|
cflags => "-DBN_DEBUG -DREF_DEBUG -DCONF_DEBUG -DBN_CTX_DEBUG -DPEDANTIC -DDEBUG_SAFESTACK -DOPENSSL_OPENBSD_DEV_CRYPTO -DOPENSSL_NO_ASM -O2 -pedantic -Wall -Wshadow -Werror -pipe",
|
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-12 13:58:07 +00:00
|
|
|
},
|
|
|
|
"debug-ben-openbsd-debug" => {
|
|
|
|
cc => "gcc",
|
2016-01-30 17:04:25 +00:00
|
|
|
cflags => "-DBN_DEBUG -DREF_DEBUG -DCONF_DEBUG -DBN_CTX_DEBUG -DPEDANTIC -DDEBUG_SAFESTACK -DOPENSSL_OPENBSD_DEV_CRYPTO -DOPENSSL_NO_ASM -g3 -O2 -pedantic -Wall -Wshadow -Werror -pipe",
|
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-12 13:58:07 +00:00
|
|
|
},
|
|
|
|
"debug-ben-debug" => {
|
|
|
|
cc => "gcc",
|
|
|
|
cflags => "$gcc_devteam_warn -DBN_DEBUG -DCONF_DEBUG -DDEBUG_SAFESTACK -DOPENSSL_NO_HW_PADLOCK -g3 -O2 -pipe",
|
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-12 13:58:07 +00:00
|
|
|
},
|
|
|
|
"debug-ben-debug-64" => {
|
|
|
|
inherit_from => [ "x86_64_asm" ],
|
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("$gcc_devteam_warn -Wno-error=overlength-strings -DBN_DEBUG -DCONF_DEBUG -DDEBUG_SAFESTACK -DDEBUG_UNUSED -g3 -O3 -pipe",
|
|
|
|
threads("${BSDthreads}")),
|
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-12 13:58:07 +00:00
|
|
|
perlasm_scheme => "elf",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "bsd-gcc-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
|
|
|
"debug-ben-debug-64-clang" => {
|
|
|
|
inherit_from => [ "x86_64_asm" ],
|
|
|
|
cc => "clang",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("$gcc_devteam_warn -Wno-error=overlength-strings -Wno-error=extended-offsetof -Wno-error=language-extension-token -Wstrict-overflow -Qunused-arguments -DBN_DEBUG -DCONF_DEBUG -DDEBUG_SAFESTACK -DDEBUG_UNUSED -g3 -O3 -pipe",
|
|
|
|
threads("${BSDthreads}")),
|
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-12 13:58:07 +00:00
|
|
|
perlasm_scheme => "elf",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "bsd-gcc-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
|
|
|
"debug-ben-debug-64-noopt" => {
|
|
|
|
inherit_from => [ "x86_64_asm" ],
|
|
|
|
cc => "gcc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("$gcc_devteam_warn -Wno-error=overlength-strings -DBN_DEBUG -DCONF_DEBUG -DDEBUG_SAFESTACK -DDEBUG_UNUSED -g3 -pipe",
|
|
|
|
threads("${BSDthreads}")),
|
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-12 13:58:07 +00:00
|
|
|
perlasm_scheme => "elf",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "bsd-gcc-shared",
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
|
|
|
|
},
|
|
|
|
"debug-ben-macos" => {
|
|
|
|
cc => "cc",
|
|
|
|
cflags => "$gcc_devteam_warn -DOPENSSL_NO_ASM -DBN_DEBUG -DCONF_DEBUG -DDEBUG_SAFESTACK -DDEBUG_UNUSED -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch i386 -O3 -DL_ENDIAN -g3 -pipe",
|
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-12 13:58:07 +00:00
|
|
|
},
|
|
|
|
"debug-ben-no-opt" => {
|
|
|
|
cc => "gcc",
|
2016-01-10 19:42:10 +00:00
|
|
|
cflags => " -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -DDEBUG_SAFESTACK -Werror -DL_ENDIAN -Wall -g3",
|
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-12 13:58:07 +00:00
|
|
|
},
|
|
|
|
"debug-ben-strict" => {
|
|
|
|
cc => "gcc",
|
2016-01-30 17:04:25 +00:00
|
|
|
cflags => "-DBN_DEBUG -DREF_DEBUG -DCONF_DEBUG -DBN_CTX_DEBUG -DCONST_STRICT -O2 -Wall -Wshadow -Werror -Wpointer-arith -Wcast-qual -Wwrite-strings -pipe",
|
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-12 13:58:07 +00:00
|
|
|
},
|
|
|
|
"debug-ben-darwin64" => {
|
|
|
|
inherit_from => [ "x86_64_asm" ],
|
|
|
|
cc => "cc",
|
Configure - Get rid of the special thread_cflag, replace with thread_scheme
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 15:51:34 +00:00
|
|
|
cflags => combine("$gcc_devteam_warn -Wno-language-extension-token -Wno-extended-offsetof -arch x86_64 -O3 -DL_ENDIAN -DMD32_REG_T=int -Wall",
|
|
|
|
threads("-D_REENTRANT")),
|
2015-03-12 13:58:07 +00:00
|
|
|
sys_id => "MACOSX",
|
Enhance and clear the support of linker flags
Some time ago, we had a ex_libs configuration setting that could be
divided into lflags and ex_libs. These got divided in two settings,
lflags and ex_libs, and the former was interpreted to be general
linking flags.
Unfortunately, that conclusion wasn't entirely accurate. Most of
those linking were meant to end up in a very precise position on the
linking command line, just before the spec of libraries the linking
depends on.
Back to the drawing board, we're diving things further, now having
lflags, which are linking flags that aren't depending on command line
position, plib_lflags, which are linking flags that should show up just
before the spec of libraries to depend on, and finally ex_libs, which
is the spec of extra libraries to depend on.
Also, documentation is changed in Configurations/README. This was
previously forgotten.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2016-02-05 10:47:14 +00:00
|
|
|
plib_lflags => "-Wl,-search_paths_first",
|
2016-01-27 23:43:25 +00:00
|
|
|
bn_ops => "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-12 13:58:07 +00:00
|
|
|
perlasm_scheme => "macosx",
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
shared_target => "darwin-shared",
|
|
|
|
shared_cflag => "-fPIC -fno-common",
|
|
|
|
shared_ldflag => "-arch x86_64 -dynamiclib",
|
|
|
|
shared_extension => ".\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
|
|
|
|
},
|
|
|
|
);
|