because this one is enabled by default anyways
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5817)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5770)

This is quick-n-dirty ad-hoc solution, the problem asks for more
elegant one...
Reviewed-by: NRichard 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: NAndy 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: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5704)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5677)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5673)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5673)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4793)

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: NRich 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: NAndy 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.

Fixes google/oss-fuzz#1244
Reviewed-by: NAndy 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: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRichard 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: NTim 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: NTim 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: NAndy 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: NAndy 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: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)

Reviewed-by: NAndy 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: NAndy 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: NAndy 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: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)

Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5533)

Fixes #5471
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5472)

The new message is geared toward issue reports
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)

Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)

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: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)

Specifically, the specific perl that was used to run Configure
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5408)

Fixes #5394
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5399)

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: NRich 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: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5371)

Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5355)

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: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5291)

[extended tests]
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5266)

Patch by @levitte.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5231)

Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5243)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5238)

INSTALL: Mention 'aria' algorithm for no-<alg>
Signed-off-by: NPeter Meerwald-Stadler <pmeerw@pmeerw.net>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5215)

Fixes #5207 (another PR)
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5210)