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)
We have never used these variables with the Unix Makefile, and there's
no reason for us to change this, so to avoid confusion, we remove them.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5545)
-fno-common was removed for all Darwin targets in
0c8734198d with rationale "it's either
'ranlib -c' or '-fno-common'." However, it's still absolutely required
in 32-bit darwin-ppc-cc. And when trying things out I didn't quite
see why it was formulated as one-or-another choice, as 'ranlib -c'
shouldn't [and doesn't] have problems with object modules without
commons. [Well, to be frank, I didn't manage to reproduce the problem
the modification was meaning to resolve either...]
Reviewed-by: Rich Salz <rsalz@openssl.org>
With this, we introduce the make variable 'libdir', which differs from
'LIBDIR' not only in casing, but also by being the absolute path to
the library installation directory. This variable is intentionally
compatible with the GNU coding standards.
When --libdir is given an absolute path, it is considered as a value
according to GNU coding standards, and the variables LIBDIR and libdir
will be this:
LIBDIR=
libdir=/absolute/path
When --libdir is given a relative path (just the name of the desired
library directory), or not given at all, it is considered as a
"traditional" OpenSSL value, and the variables LIBDIR and libdir will
be this:
LIBDIR=relativepath
libdir=$(INSTALLTOP)/$(LIBDIR)
Fixes#5398
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5446)
The reason for this is that some of the C flags affect built in macros
that we may depend on.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5436)
If the configured value is the empty string, give them a sane default.
Otherwise, give them the configured value prefix with $(CROSS_COMPILE)
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)
It was inconsistent to see this specific command have
'$(CROSS_COMPILE)' in its value when no other command did.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)
In previous OpenSSL versions, this letter was part of the make
variable AR. However, following the usual convention (read: GNU),
this letter is supposed to be part of ARFLAGS.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5386)
Avoid using crypto/modes/ghash-ia64.s, as it uses features that are
explicitely prohibited on VMS.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5357)
The make variables LIB_CFLAGS, DSO_CFLAGS and so on were used in
addition to CFLAGS and so on. This works without problem on Unix and
Windows, where options with different purposes (such as -D and -I) can
appear anywhere on the command line and get accumulated as they come.
This is not necessarely so on VMS. For example, macros must all be
collected and given through one /DEFINE, and the same goes for
inclusion directories (/INCLUDE).
So, to harmonize all platforms, we repurpose make variables starting
with LIB_, DSO_ and BIN_ to be all encompassing variables that
collects the corresponding values from CFLAGS, CPPFLAGS, DEFINES,
INCLUDES and so on together with possible config target values
specific for libraries DSOs and programs, and use them instead of the
general ones everywhere.
This will, for example, allow VMS to use the exact same generators for
generated files that go through cpp as all other platforms, something
that has been impossible to do safely before now.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5357)
Instead of having the knowledge of the exact flags to run the C
preprocessor only and have it output on standard output in the deeper
recesses of the build file template, make it a config parameter, or
rely on build CPP in value ('$(CC) -E' on Unix).
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5356)
All VMS config targets were literally copies of each other, only
differing in what argument the parameter seeking function vms_info()
received (the pointer size).
This could be hugely simplified by letting vms_info() detect what
pointer size was desired from the desired config target name instead.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5364)
It was a bit absurd to have this being specially handled in the build
file templates, especially that we have the 'includes' attribute.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5296)
Configurations/descrip.mms.tmpl didn't treat the includes config
attribute very well. In fact, it didn't treat it at all!
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5295)
If a module is disablable (i.e. can be configured with 'no-FOO'), the
resulting header file needs to be guarded with a check of the
corresponding OPENSSL_NO_FOO. While this seem fairly innocuous, it
has an impact on the information in util/*.num, generated by mkdef.pl.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5275)
Most modules are direct implementations of openssl application
sub-commands, but some constitute a support library, which can be used
by more than one program (and is, incidently, by test/uitest).
For practical purposes, we place the support library modules in a
private, static library.
Finally, there are some modules that don't have direct references in
the rest of the apps code, but are still crucial. See them as some
kind of extra crt0 or similar for your platform.
Inspiration from David von Oheimb
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5222)
For proper escaping, we need the direct perl variable values, not a
make variable reference.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5196)
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)
vc_wince_info()->{defines} was left around, when it should be
vc_wince_info()->{cppflags}
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5182)
There were a small number that inherited no BASE, the now inherit
BASE_unix.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)
Ideally, each config target should inherit a base to get their
platform specific defaults. Unfortunately, that is currently not the
case, so we duplicate the Unixly defaults from the BASE_unix template
into the DEFAULT template.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)
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)
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)
Since libssl requires libcrypto and libcrypto.pc already has
Libs.private set exactly the same, there's no reason to repeat it in
libssl.pc.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5134)
Even -pthread gets treated that way. The reason to do this is so it
ends up in 'Libs.private' in libcrypto.pc.
Fixes#3884
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5134)
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)
The uClinux targets included some attributes that would result in
circular references of CFLAGS and LDCLAGS.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5034)
