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)
