Also took away the internal 'debug-linux-ia32-aes' config target, as
it's broken (refers to files that no longer exist).
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9166)
As preparation for moving asm file specs to build.info files, we must
make sure there is still some base information to help select the
correct files.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9166)
This file information was hidden in config target files, when they
should really be part of build.info like any other file we build
from. With build.info variables, the task became much easier.
We take the opportunity to move apps_init_src and apps_aux_src to
apps/build.info as well, and to clean up apps/build.info.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9166)
As preparation for moving uplink file specs to build.info files, we
must make sure there is still some base information to help select the
correct files.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9166)
This will allow building variables on other variables, and to have
conditions based on variable contents.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9166)
Make sure that the combination of no-ec with no-dh builds successfully.
If neither ec or dh are available then TLSv1.3 is not possible.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9156)
Now that we have TLSv1.3 FFDHE support there is no reason why we should
not allow TLSv1.3 to be used in a no-ec build. This commit enables that
to happen.
It also fixes no-ec which was previously broken.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9156)
Variables have the syntax defined with this regular expression:
\$([[:alpha:]_][[:alnum:]_]*)
They are always local to the build.info they are defined in, and are
defined like this:
$VAR=text
Expansion is done very simply, any reference to the variable (with the
exact same variable syntax) is replaced with its defined value.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9144)
Make sure that each basename only appears once. This is due to the
static library archiver on Unix, that indexes archived object files by
base name only, thereby making base name clashes... interesting.
This is a safety net for OpenSSL developer!
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9133)
The DEBUG_SAFESTACK preprocessor define is obsolete since 2008
when the non-safestack code was removed by commit 985de86340.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9070)
There are various C macro definitions that are passed via the compiler
to enable AES assembler optimisation. We need to make sure that these
defines are also passed during compilation of the FIPS module.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9038)
We add the extra warning and sanitizer options to check our code,
which is entirely in C. We support C++ compilers uniquely for the
sake of certain external test suites, and those projects can probably
sanitize their own code themselves.
[extended tests]
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9013)
In the development of the CRMF sub-system, there seems to have been
some confusion as to what configuration option should be used.
'no-crmf' was added, but the C macro guards were using OPENSSL_NO_CMP
rather than OPENSSL_NO_CRMF...
In fact, we want 'no-cmp', but since the CRMF code is part of CMP, we
need 'no-crmf' to depend on 'no-cmp'. We do this by making 'crmf' a
silent "option" that get affected by 'cmp' by way of %disable_cascades.
This allows options to be "aliases" for a set of other ones, silent or
not.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8897)
The reason is that the shared-info attributes may depend on %disabled,
so we need to process all enablings/disablings first.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8846)
Because we depend on knowing if clang's address, memory or undefinedbehavior
sanitizers are enabled, we make an extra effort to detect them among the
C flags, and adjust the %disabled values accordingly.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/8778)
Disabling one thing may mean having to disable other things as well.
We already have a process to auto-disable things through cascading,
but that was under-used.
Making the cascading mechanism available through a function to be
called to disable stuff makes it more automatic, and helps us when we
forget how different disabling options affect others.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8812)
This came about with the realisation that upper case CFLAGS, LDFLAGS
and so on aren't treated much after that, and this makes figuring out
user added flags significantly easier, just look in %config.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8812)
While we're at it, sort out inconsistencies with the build of modules:
- not building shared libraries means not building dynamic engines.
However, other modules may still be built.
- not having DSO functionality doesn't mean not to build modules (even
though we can't use them from apps linked with libraries that are
built this way).
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8623)
SHARED_SOURCE is reserved for products that are expected to come in
dual shared / non-shared form, i.e. the routine libraries like
libcrypto and libssl, to distinguish source that should only appear in
their shared form.
Modules are always shared, so there's no need for them to have this
type of distinction.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8623)
Removing the option entirely would break builds unnecessarily, so
let's make it deprecated.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8632)
'no-dso' is meaningless, as it doesn't get any macro defined.
Therefore, we remove all checks of OPENSSL_NO_DSO. However, there may
be some odd platforms with no DSO scheme. For those, we generate the
internal macro DSO_NONE aand use it.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/#8622)
The indentation in the Configure file is currently very strange when
viewed in an editor with a tab width of four spaces, because it has
mixed tab-and-whitespace indentation, which was apparently done with
a tab width of eight spaces.
This commit converts all tabs to spaces using expand(1) with default
settings. To verify that there are only whitespace changes, use
git show --ignore-space-change <this commit>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8492)
in INSTALL, Configure, crypto/build.info, include/openssl/crmferr.h,
crypto/err/, include/openssl/err.h, and (to be updated:) util/libcrypto.num
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7646)
This disabled the tracing functionality by making functions do
nothing, and making convenience macros produce dead code.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8198)
The "hw" and "hw-.*" style options are historical artifacts, sprung
from the time when ENGINE was first designed, with hardware crypto
accelerators and HSMs in mind.
Today, these options have largely lost their value, replaced by
options such as "no-{foo}eng" and "no-engine".
This completes the transition by making "hw" and "hw-.*" deprecated,
but automatically translated into more modern variants of the same.
In the process, we get rid of the last regular expression in
Configure's @disablables, a feature that was ill supported anyway.
Also, padlock now gets treated just as every other engine.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8380)
Since the padlock code is an engine, the assembler is for a module,
not a library link to when building a program... there's a
distinction.
Fixes#2311
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8220)
This makes `--strict-warnings` into a compiler pseudo-option, i.e. it
gets treated the same way as any other compiler option given on the
configuration command line, but is retroactively replaced by actual
compiler warning options, depending on what compiler is used.
This makes it easier to see in what order options are given to the
compiler from the configuration command line, i.e. this:
./config -Wall --strict-warnings
would give the compiler flags in the same order as they're given,
i.e.:
-Wall -Werror -Wno-whatever ...
instead of what we got previously:
-Werror -Wno-whatever ... -Wall
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8239)
There are times when one might want to use something like
DEFINE_STACK_OF in a .c file, because it defines a stack for a type
defined in that .c file. Unfortunately, when configuring with
`--strict-warnings`, clang aggressively warn about unused functions in
such cases, which forces the use of such DEFINE macros to header
files.
We therefore disable this warning from the `--strict-warnings`
definition for clang.
(note for the curious: `-Wunused-function` is enabled via `-Wall`)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8234)
The only thing that makes an ENGINE module special is its entry
points. Other than that, it's a normal dynamically loadable module,
nothing special about it. This change has us stop pretending anything
else.
We retain using ENGINE as a term for installation, because it's
related to a specific installation directory, and we therefore also
mark ENGINE modules specifically as such with an attribute in the
build.info files.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8147)
It was an ugly hack to avoid certain problems that are no more.
Also added GENERATE lines for perlasm scripts that didn't have that
explicitly.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8125)
Among others, this avoids having special variables like
PROGRAMS_NO_INST. Instead, we can have something like this:
PROGRAMS{noinst}=foo bar
Configure itself is entirely agnostic to these attributes, they are
simply passed to the build file templates, to be used as they see fit.
Attributes can also have values, for example:
SCRIPTS{linkname=foo}=foo.pl
This could help indicate to build file templates that care that the
perl script 'foo.pl' should also exist with the name 'foo', preferably
as a symbolic link.
Fixes#7568
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7581)
Now that we have the names of libraries on different systems
established through platform modules, we can remove the old structure
to establish the same thing, i.e. $unified_info{sharednames} and
$unified_info{rename}. That means removing support for the RENAME and
SHARED_NAME keywords in build.info as well.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
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)
Add platform::VMS, which is a generic VMS module. Additional modules
to support specific building aspects (such as specific compilers) may
be added later, but since we currently work on file names and those
are generic enough, this is also enough.
This reworks Configurations/descrip.mms.tmpl to work out product names
in platform::VMS terms. Something to be noted is that the new
functionality ignores the *_extension config attributes, as they were
never used. VMS is very consistent in its use of extensions, so there
is no reason to believe much will change in this respect.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
Add platform::Windows, which is a generic Windows module, and
platform::Windows::MSVC, which is a module specifically for MS Visual
C.
This reworks Configurations/windows-makeffile.tmpl to work out product
names in platform::Windows. Something to be noted is that the new
functionality ignores the *_extension config attributes, as they were
never used.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
Based originally on github.com/dfoxfranke/libaes_siv
This creates an SIV128 mode that uses EVP interfaces for the CBC, CTR
and CMAC code to reduce complexity at the cost of perfomance. The
expected use is for short inputs, not TLS-sized records.
Add multiple AAD input capacity in the EVP tests.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3540)
Since `$config{version}` and `$config{version_num}` were removed
in commit 3a63dbef15, the configure output displays an empty
version number string in parentheses instead of the version number.
This pull request fixes that by adding new config variables
`version` and `full_version`, analogous to `OPENSSL_VERSION_STR`
and `OPENSSL_FULL_VERSION_STR`.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7841)
Allow users to disable ktls using the "no-ktls" option.
Also, disable ktls when cross-compiling, non-linux, or too-old-kernel.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Yang <yang.yang@baishancloud.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5253)
Previously, the API version limit was indicated with a numeric version
number. This was "natural" in the pre-3.0.0 because the version was
this simple number.
With 3.0.0, the version is divided into three separate numbers, and
it's only the major number that counts, but we still need to be able
to support pre-3.0.0 version limits.
Therefore, we allow OPENSSL_API_COMPAT to be defined with a pre-3.0.0
style numeric version number or with a simple major number, i.e. can
be defined like this for any application:
-D OPENSSL_API_COMPAT=0x10100000L
-D OPENSSL_API_COMPAT=3
Since the pre-3.0.0 numerical version numbers are high, it's easy to
distinguish between a simple major number and a pre-3.0.0 numerical
version number and to thereby support both forms at the same time.
Internally, we define the following macros depending on the value of
OPENSSL_API_COMPAT:
OPENSSL_API_0_9_8
OPENSSL_API_1_0_0
OPENSSL_API_1_1_0
OPENSSL_API_3
They indicate that functions marked for deprecation in the
corresponding major release shall not be built if defined.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7724)
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7724)
We're strictly use version numbers of the form MAJOR.MINOR.PATCH.
Letter releases are things of days past.
The most central change is that we now express the version number with
three macros, one for each part of the version number:
OPENSSL_VERSION_MAJOR
OPENSSL_VERSION_MINOR
OPENSSL_VERSION_PATCH
We also provide two additional macros to express pre-release and build
metadata information (also specified in semantic versioning):
OPENSSL_VERSION_PRE_RELEASE
OPENSSL_VERSION_BUILD_METADATA
To get the library's idea of all those values, we introduce the
following functions:
unsigned int OPENSSL_version_major(void);
unsigned int OPENSSL_version_minor(void);
unsigned int OPENSSL_version_patch(void);
const char *OPENSSL_version_pre_release(void);
const char *OPENSSL_version_build_metadata(void);
Additionally, for shared library versioning (which is out of scope in
semantic versioning, but that we still need):
OPENSSL_SHLIB_VERSION
We also provide a macro that contains the release date. This is not
part of the version number, but is extra information that we want to
be able to display:
OPENSSL_RELEASE_DATE
Finally, also provide the following convenience functions:
const char *OPENSSL_version_text(void);
const char *OPENSSL_version_text_full(void);
The following macros and functions are deprecated, and while currently
existing for backward compatibility, they are expected to disappear:
OPENSSL_VERSION_NUMBER
OPENSSL_VERSION_TEXT
OPENSSL_VERSION
OpenSSL_version_num()
OpenSSL_version()
Also, this function is introduced to replace OpenSSL_version() for all
indexes except for OPENSSL_VERSION:
OPENSSL_info()
For configuration, the option 'newversion-only' is added to disable all
the macros and functions that are mentioned as deprecated above.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7724)
Without this precaution, we end up having directory targets depend on
shlib object files for which there are no rules.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7644)
We kept a number of arrays of directory names to keep track of exactly
which directories to look for build.info. Some of these had the extra
function to hold the directories to actually build.
With the added SUBDIRS keyword, these arrays are no longer needed.
The logic for skipping certain directories needs to be kept, though.
That is now very much simplified, and is made opportunistic.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7558)
We have $config{openssl_algorithm_defines}, $config{openssl_other_defines}
and $config{openssl_thread_defines}. These are treated exactly the same
in include/openssl/opensslconf.h.in, so having them separated into three
different databases isn't necessary, the reason for the separation being
long gone. Therefore, we collapse them into one and the same,
$config{openssl_feature_defines}.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7558)
This adds a keyword SUBDIRS for build.info, to be used like this:
SUBDIRS=foo bar
This tells Configure that it should look for 'build.info' in the
relative subdirectories 'foo' and 'bar' as well.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7558)
Sometimes, some specific program or object file might need an extra
macro definition of its own. This allows that to be easily done.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7553)
Remove GMAC demo program because it has been superceded by the EVP MAC one
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7548)
Just refering to a hash table element as an array reference will
automatically create that element. Avoid that by defaulting to
a separate empty array reference.
Fixes#7543
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7544)
This makes sure that any resulting directory target in the build files
also depend on object files meant for shared libraries.
As a side effect, we move the production of the dirinfo structure from
common.tmpl to Configure, to make it easier to check the result.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7452)
The new Configure summary box (41349b5e6d) now hides the warning
about the missing seed source (2805ee1e09) too much. To make it
more visible again, add warning markers.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7509)
In commit 820e414d28 (pr #5247) the summary output of the
Configure command was optimized towards instructing people
how to create issue reports.
It turned out that the wording of this message can confuse new
OpenSSL users and make them think that they are seeing an error
message. This commit makes the summary output start with a success
to prevent a misunderstanding. Also it gives more hints to new
OpenSSL users.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7499)
We didn't notice the error because it all happened in the top directory.
Now that we use .ld files in subdirectories, the bug became apparent.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7347)
The generation of linker scripts was badly balanced, as all sorts of
platform dependent stuff went into the top build.info, when that part
should really be made as simply and generic as possible.
Therefore, we move a lot of the "magic" to the build files templates,
since they are the place for platform dependent things. What remains
is to parametrize just enough in the build.info file to generate the
linker scripts correctly for each associated library.
"linker script" is a term usually reserved for certain Unix linkers.
However, we only use them to say what symbols should be exported, so
we use the term loosely for all platforms. The internal extension is
'.ld', and is changed by the build file templates as appropriate for
each target platform.
Note that this adds extra meaning to the value of the shared_target
attribute.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7333)
This will allow to have different object files for different products,
even if they share the same source code, and possibly different builds
for those different object files.
For example, one can have something like this:
SOURCES[libfoo]=cookie.c
INCLUDES[libfoo]=include/foo
SOURCES[libbar]=cookie.c
INCLUDES[libbar]=include/bar
This would mean that the object files and libraries would be build
somewhat like this:
$(CC) -Iinclude/foo -o libfoo-lib-cookie.o cookie.c
$(AR) $(ARFLAGS) libfoo.a libfoo-lib-cookie.o
$(CC) -Iinclude/bar -o libbar-lib-cookie.o cookie.c
$(AR) $(ARFLAGS) libbar.a libbar-lib-cookie.o
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7159)
Instead, use the include settings from the products later in the process,
making it possible to have different includes for two different libraries
that share the same source code.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7159)
The option has no meaning on Darwin, but it can bail out in combination
with -fembed-bitcode or -no-integrated-as...
Reviewed-by: Richard Levitte <levitte@openssl.org>
This is done by calling die again, just make sure to reset the __DIE__
handler first.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6776)
On the same note, change the 'NASM not found' message to give specific
advice on how to handle the failure.
Fixes#6765
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6771)
OpenSSL 1.1.0 supports the use of this environment variable for
passing to the build files. For the sake of backward compatibility,
we keep it.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/6668)
This allows to specify flags specific to shared build, e.g.
'bin_lflags => shared("-Wl,-bsvr4")'.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6453)
Earlier Apple Xcode compilers, e.g. one targeting Mac OS X 10.7, don't
support dependency generation and one still has to use makedepend. It's
unclear when it was fixed, but all clang-based Apple compilers seem to
support -M options.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6169)
config probe doesn't work in cross-compile scenarios or with clang.
In addition consolidate -Qunused-arguments handling.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6174)
Computing the value of the GENERATED variable in the build file
templates is somewhat overcomplicated, and because of possible
duplication errors, changes are potentially error prone.
Looking more closely at how this list is determined, it can be
observed that the exact list of files to check is consistently
available in all the values found in the %unified_info tables
'depends', 'sources' and 'shared_sources', and all that's needed is to
filter those values so only those present as keys in the 'generate'
table are left.
This computation is also common for all build files, so due to its
apparent complexity, we move it to common0.tmpl, with the result left
in a global variable (@generated), to be consumed by all build file
templates.
common0.tmpl is included among the files to process when creating
build files, but unlike common.tmpl, it comes first of all.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5930)
This is quick-n-dirty ad-hoc solution, the problem asks for more
elegant one...
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5755)
The macros resulting from the dso_scheme attribute were defined for
libraries only, but there's a test program that uses the macros as
well. The easier way is to move the handling of this macro to
crypto/include/internal/dso_conf.h and having the modules that need it
include it.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5733)
Add it to apps as well as libraries.
Fix the copyright year generation.
Thanks to user RTT for pointing this out.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5704)
Occasionally you have to pass -no-integrated-as to clang, but we
consider any -no-option as no-option. Don't touch -no-integrated-as.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5613)
There were a few environment variables that we supported in earlier
Configure versions which got transfered to the %user table. This
change makes sure that we still support them, by simply pre-populating
the corresponding %user entries with those environment values.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5641)
The original intent was that if someone had a "make variable" set in
any kind of way, be it as an environment variable or as an argument to
Configure, we wouldn't allow compiler or linker flags as arguments as
well. That made both of these configurations equivalently impossible:
./Configure target CFLAGS=-foo -lextra
CFLAGS=-foo ./Configure target -lextra
While this makes things look nice and consistent, real world use makes
this hard, as many projects where OpenSSL is a component also set
these variables for other components that use GNU autotools.
Therefore, we need to adapt our Configure accordingly. By
consequence, the two Configure lines above will not be equivalent any
more:
./Configure target CFLAGS=-foo -lextra
This command line will still fail, because the "make variable" was
given as a command line argument. This cannot be a mistake and is
therefore not allowed.
CFLAGS=-foo ./Configure target -lextra
This command line will work, but because there is a linker flag as
a command line argument, the environment (i.e. CFLAGS) is ignored.
That isn't quite consistent with the previous command, but is the old
Configure behavior, before the support for "make variables" was added,
and is therefore the backward compatible behavior.
Fixesgoogle/oss-fuzz#1244
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5641)
The Debian build system uses a `debian' target which sets CFLAGS and
then we have for instance debian-amd64 which inherits from
linux-x86_64 and debian [0]. So far so good.
Unless there are different suggestions how to do this, I would keep it.
However since the target name does not start with `linux', the build
system does not enable the afalg engine. So in order to get enabled, I
added a
`enable => [ "afalgeng" ],'
to the generic linux config which sets it explicit (as suggested by
Richard Levitte). Having this set, we can check for it instead matching
the target name.
[0] https://sources.debian.org/src/openssl/1.1.0g-2/Configurations/20-debian.conf/
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5169)
There are things depending on configdata.pm. However, it's perfectly
possible that there is one in the source directory from a previous
build, and that might disrupt an out of source build. To avoid this
conflict, make sure never to use the source tree configdata.pm in that
case, i.e. make the hard assumption that it's a generated file in the
build tree, which it is.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5546)
When generating the correct inclusion directory for DEPEND, we mangled
it to be relative to the build or the source directory. However, the
value we handle already come with a correct directory, so we only need
to use it as is.
Fixes#5543
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5546)
We're currently using the attributes 'defines', 'cppflags', 'cflags'
etc quite liberally, with no regard for where that ends up. Quite a
few of those flags are actually only relevant for the libraries
(mostly libcrypto), so it's safe to say that those could be applied to
the libraries only.
So, we move some of those flags to 'lib_defines', 'lib_cppflags',
'lib_cflags', etc.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5560)
The check to detect if env / make variables conflicted with compiler /
linker flags on the configure command line went a little too far, and
would stop the configuration process if any such command line flag was
given, with no regard for the env / make variables at all.
This change refines the check so the stop only gets triggered if any
such flags were given AND any of the corresponding variables are set.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5561)
Note that this might give surprising results if someone forgets an environment
variable that has been set previously.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
Passing flags "discovered" by 'config' on the command line to
'Configure' mixes them up with flags given by the user. That is
contrary to their intention, so they need to be passed in a different
manner.
Enter the environment variables __CNF_CPPDEFINES, __CNF_CPPINCLUDES,
__CNF_CPPFLAGS, __CNF_CFLAGS, __CNF_CXXFLAGS, __CNF_LDFLAGS, and
__CNF_LDLIBS, initialised by 'config', and then used by Configure to
initialise these %config values: defines, includes, cppflags, cflags,
cxxflags, lflags, and ex_libs.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
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)
Because there are already attributes with the dso_ prefix that are
used instead of the corresponding lib_ attributes rather than in
addition to them, it gets confusing to have similar or exactly the
same attributes working with different semantics on Unix.
So we rename those by changing the prefix dso_ to module_, and having
those work just like the shared_ attributes, but for DSOs.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
No more special casing for that one, and this means it gets displayed
by 'perl configdata.pm --make-variables' among all the others.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)
Most of all, this is so it doesn't output mysterious text when we're
treating the phony config targets LISH, HASH and TABLE
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5383)
configdata.pm -d prints out a lot of information, including a table
of what features are disabled, why, and the effect of that disablement
(in terms of preprocessor symbols defined and directories skipped).
The first column is already auto-sized, to easily accomodate future
disableable features with long names. Also auto-size the second column,
to accomodate future reasons for disablement with long names as well.
Failing to take such precautions results in stderr spew from
configdata.pm -d when such long reasons are in use:
Negative repeat count does nothing at ./configdata.pm line 14504.
Such output is pretty distracting from the actual desired output,
so try to avoid it if possible.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5371)
The contents of that attribute is C file names, not object file names.
This went undetected because quite a lot of systems have assembler
implementations anyway, so setting OPENSSL_CPUID_OBJ was correct for
them.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5291)
Patch by @levitte.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5231)
INSTALL: Mention 'aria' algorithm for no-<alg>
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5215)
This message will ONLY be visible in OpenSSL 1.1.1, it will not show
in 1.1.1a or any other release or update.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5185)
The additional possibility is:
perl configdata.pm --options Display the features, both
enabled and disabled, and
display defined macro and
skipped directories where
applicable.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5185)
The "make variable" information displayed by Configure was selective
and incomplete, and possibly undesirable (too verbose).
Instead, we make configdata.pm and have the user run it to get the
information they desire, and also make it possible to have it perform
a reconfiguration.
Possibilities so far:
perl configdata.pm --dump Displays everything (i.e. the
combined output from
--command-line, --environment,
--make-variables and
--build-parameters.
perl configdata.pm --command-line Displays the config command
line.
perl configdata.pm --envirnoment Displays the recorded
environment variables.
perl configdata.pm --make-variables Displays the configured "make
variables".
perl configdata.pm --build-parameters Displays the build file and
the template files to create
it.
perl configdata.pm --reconfigure Re-runs the configuration with
the recorded environment
variables.
--verbose can be used to have --reconfigure be a bit more verbose.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5185)
C++ flags got the same config target value as C flags, but then
nothing else happened while C flags get all kinds of stuff added to
them (especially when --strict-warnings is used).
Now, C++ flags get the exact same treatment as C flags. However, this
only happens when a C++ compiler is specified, to avoid confusing
messages about added C++ flags.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5181)
Default values belong in the DEFAULT config target template, in
Configurations/00-base-templates.conf.
This isn't a complete move, but takes care of the most blatant
examples.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)
Support the following "make variables":
AR (GNU compatible)
ARFLAGS (GNU Compatible)
AS (GNU Compatible)
ASFLAGS (GNU Compatible)
CC (GNU Compatible)
CFLAGS (GNU Compatible)
CXX (GNU Compatible)
CXXFLAGS (GNU Compatible)
CPP (GNU Compatible)
CPPFLAGS (GNU Compatible)
CPPDEFINES List of CPP macro definitions. Alternative for -D
CPPINCLUDES List of CPP inclusion directories. Alternative for -I
HASHBANGPERL Perl invocation to be inserted after '#!' in public
perl scripts.
LDFLAGS (GNU Compatible)
LDLIBS (GNU Compatible)
RANLIB Program to generate library archive index
RC Program to manipulate Windows resources
RCFLAGS Flags for $(RC)
RM (GNU Compatible)
Setting one of these overrides the corresponding data from our config
targets. However, flags given directly on the configuration command
line are additional, and are therefore added to the flags coming from
one of the variables above or the config target.
Fixes#2420
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)
C preprocessor flags get separated from C flags, which has the
advantage that we don't get loads of macro definitions and inclusion
directory specs when linking shared libraries, DSOs and programs.
This is a step to add support for "make variables" when configuring.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)
We incorrectly assumed that explicit dependencies meant that the
source directory would be added for inclusion. However, if the
dependent file is generated, it's stored in the build directory, and
that should be used for inclusion rather than the source directory.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5153)
This ensures that only one set of includes is associated with each
object file, reagardless of where it's used.
For example, if apps/build.info has this:
SOURCE[openssl]=foo.c
INCLUDE[openssl]=.. ../include
and test/build.info has this:
SOURCE[footest]=../apps/foo.c
INCLUDE[footest]=../include
The inclusion directories used for apps/foo.o would differ depending
on which program's dependencies get generated first in the build file.
With this change, all those INCLUDEs get combined into one set of
inclusion directories tied to the object file.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5153)
So far, we've placed all extra library related flags together, ending
up in the make variable EX_LIBS. This turns out to be problematic, as
for example, some compilers don't quite agree with something like
this:
cc -o foo foo.o -L/whatever -lsomething
They prefer this:
cc -L/whatever -o foo foo.o -lsomething
IBM's compiler on OS/390 is such a compiler that we know of, and we
have previously handled that as a previous case.
The answer here is to make a more general solution, where linking
options are divided in two parts, where one ends up in LDFLAGS and
the other in EX_LIBS (they corresponds to what is called LDFLAGS and
LDLIBS in the GNU world)
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5033)
Following the changes that removed Makefile.shared, we also changed
the generation of .def / .map / .opt files from ordinals more
explicit, removing the need to the "magic" ORDINALS declaration.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4993)
This got lost somehow. The methods to do makedepend on Windows and
VMS are hard coded for cl (Windows) and CC/DECC (VMS), because that's
what we currently support natively.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4907)
This makes it possible to add build.info statements for using resource
files as well as linker scripts (.def for Windows, .map for Unix, and
.opt for VMS) is if they were source files. This requires changes in
the build file templates.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)
This will replace the use of Makefile.shared
This also means a small adjustment on how the attributes dso_cflags,
dso_cxxflags and dso_lflags are treated. They were previously treated
as an extension to shared_cflag, shared_cxxflag and shared_ldflag, but
they should really be regarded as alternatives instead, for example
for darwin, where -dynamiclib is used for shared libraries and -bundle
for DSOs.
We take the opportunity to clean out things that are redundant or
otherwise superfluous (for example the check of GNU ld on platforms
where it never existed).
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)
It will return the last expression from the input file.
We also use this in read_config, which slightly changes what's
expected of Configurations/*.conf. They do not have to assign
%targets specifically. On the other hand, the table of configs MUST
be the last expression in each of those files.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)
It's better to inform the user about this than silently ignoring
something that the user might expect to work, somehow.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4818)
In other words, make the following possible:
./config CC=clang
or
./Configure CC=clang linux-x86_64
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4818)
There are cases when we overwrite %ENV values, and while this is
perfectly fine on some platforms, it isn't on others, because the
Configure script isn't necessarely run in a separate process, and
thus, changing %ENV may very well change the environment of the
calling shell. VMS is such a platform.
Furthermore, saving away values that we use also allow us to save them
in configdata.pm in an effective way, and recall those values just as
effectively when reconfiguring. Also, this makes sure that we do use
the saved away values when reconfiguring, when the actual environment
variables might otherwise affect us.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4818)
Around 138 distinct errors found and fixed; thanks!
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3459)
'rsa', 'sha' and 'tlsext' can't be disabled, not even as a consequence
of other conditions, so having cascading disables that depend on them
is futile. Clean up!
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4693)
SM3 is a secure hash function which is part of the Chinese
"Commercial Cryptography" suite of algorithms which use is
required for certain commercial applications in China.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4616)
The warning flag in question was added in GCC version 6, hence
addition has to be conditional.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4401)
Detect clang even if it's disguised, e.g. cross-compiler or invoked by
explicit path name, and add the option based on that.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4383)
crypto/rand/rand_egd.c makes extensive use of stdio functions. When
they are disabled, it makes sense to disable egd as well.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4358)
The commit subject is a bit misleading in sense that decisions affect
only gcc and gcc-alikes, like clang, recent icc...
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4281)
Instead of having perl modules under test/testlib, util and util/perl,
consolidate them all to be inside util/perl.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4069)
File::Glob::glob is deprecated, it's use generates this kind of
message:
File::Glob::glob() will disappear in perl 5.30. Use File::Glob::bsd_glob() instead. at ../master/Configure line 277.
So instead, use a construction that makes the caller glob() use
File::Glob::bsd_glob().
Note that we're still excluding VMS, as it's directory specs use '['
and ']', which have a different meaning with bsd_glob and would need
some extra quoting. This might change, but later.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4040)
$(SHLIB_MAJOR).$(SHLIB_MINOR) is really a synonym for
$(SHLIB_VERSION_NUMBER), and is therefore an added complexity,
so better to use $(SHLIB_VERSION_NUMBER) directly. SHLIB_MAJOR and
SHLIB_MINOR are now unused, but are kept around purely as information
in case someone relies on their existence.
At the same time, add support for custom shared library extensions
with the three new Makefile variables SHLIB_EXT, SHLIB_EXT_SIMPLE and
SHLIB_EXT_IMPORT. By default, they hold the variants of shared
library extensions we support. On mingw and cygwin, SHLIB_EXT_IMPORT
is defined; on all other Unix platforms, it's empty.
An example to get shared libraries with a slightly different SOVER name:
$ make SHLIB_EXT='.$(SHLIB_VERSION_NUMBER).so'
Fixes#3902
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3964)
Add a new config param to specify how the CSPRNG should be seeded.
Illegal values or nonsensical combinations (e.g., anything other
than "os" on VMS or HP VOS etc) result in build failures.
Add RDSEED support.
Add RDTSC but leave it disabled for now pending more investigation.
Refactor and reorganization all seeding files (rand_unix/win/vms) so
that they are simpler.
Only require 128 bits of seeding material.
Many document improvements, including why to not use RAND_add() and the
limitations around using load_file/write_file.
Document RAND_poll().
Cleanup Windows RAND_poll and return correct status
More completely initialize the default DRBG.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/3965)
Instead, make it possible to disable the console reader that's part of
the UI module. This makes it possible to use the UI API and other UI
methods in environments where the console reader isn't useful.
To disable the console reader, configure with 'no-ui-console' /
'disable-ui-console'.
'no-ui' / 'disable-ui' is now an alias for 'no-ui-console' /
'disable-ui-console'.
Fixes#3806
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3820)
There are no public TLSv1_3_*method() functions so
OPENSSL_NO_TLS1_3_METHOD doesn't make any sense and should be removed.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3800)
This STORE module adds the following functionality:
- A function OSSL_STORE_open(), OSSL_STORE_load() and OSSL_STORE_close()
that accesses a URI and helps loading the supported objects (PKEYs,
CERTs and CRLs for the moment) from it.
- An opaque type OSSL_STORE_INFO that holds information on each loaded
object.
- A few functions to retrieve desired data from a OSSL_STORE_INFO
reference.
- Functions to register and unregister loaders for different URI
schemes. This enables dynamic addition of loaders from applications
or from engines.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3542)
For DES and 3DES based ciphers are also enabled by this option.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3707)
"Configuring..." was displayed with './Configure LIST'. This reorders
the display of that line to happen after the "targets" LIST, TABLE and
HASH have been checked.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3702)
Since the clang_devteam_warnings are appended to the gcc_devteam_warnings
when strict-warnings are requested, any items present in both the gcc
and clang variables will be duplicated in the cflags used for clang builds.
Remove the extra copy from the clang-specific flags in favor of the
gcc_devteam_warnings that are used for all strict-warnings builds.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3239)
clang already has it; let's flip the switch and deal with the fallout.
Exclude -Wunused-parameter, as we have many places where we keep unused
parameters to conform to a uniform vtable-like interface.
Also exclude -Wmissing-field-initializers; it's okay to rely on
the standard-mandated behavior of filling out with 0/NULL.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3239)
Configure started with 'require 5.10.0', but if executed by older perl
it failed with "might be runaway multi-line // string" instead of
naturally expected "Perl v5.10.0 required--this is only v5.x.y".
Reviewed-by: Richard Levitte <levitte@openssl.org>
Fix some comments too
[skip ci]
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3069)
Make it disabled by default. When TLSv1.3 is out of draft we can remove
this option and have it enabled all the time.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3022)
For each platform, we may need to perform some basic checks to see
that available tools perform as we expect them.
For the moment, the added checkers test that Perl gives the expected
path format. This should help MingW users to see if they run an
appropriate Perl implementation, for example.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2851)
This removes the fips configure option. This option is broken as the
required FIPS code is not available.
FIPS_mode() and FIPS_mode_set() are retained for compatibility, but
FIPS_mode() always returns 0, and FIPS_mode_set() can only be used to
turn FIPS mode off.
Reviewed-by: Stephen Henson <steve@openssl.org>
Avoid a -Wundef warning in refcount.h
Avoid a -Wundef warning in o_str.c
Avoid a -Wundef warning in testutil.h
Include internal/cryptlib.h before openssl/stack.h
to avoid use of undefined symbol OPENSSL_API_COMPAT.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2712)
There has never been any gcc option of that kind.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2705)
