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)
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)
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)
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)
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)
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)
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)
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)
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)
Ignore libssl.map/libcrypto.map instead of ssl.map/crypto.map
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4932)
Because this also includes handling all sorts of non-object files when
linking a program, shared library or DSO, this also includes allowing
general recognition of files such as .res files (compiled from .rc
files), or .def / .map / .opt files (for export and possibly
versioning of public symbols only).
This does mean that there's a tangible change for all build file
templates: they must now recognise and handle the `.o` extension,
which is used internally to recognise object files internally. This
extension was removed by common.tmpl before this change, but would
mean that the platform specific templates wouldn't know if "foo.map"
was originally "foo.map.o" (i.e. an object file in its own right) or
"foo.map" (an export definition file that should be treated as such,
not as an object file).
For the sake of simplifying things, we also modify util/mkdef.pl to
produce .def (Windows) and .opt (VMS) files that don't need additional
hackery.
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)
This small change in the Unix template and shared library build
scripts enables building "variant" shared libraries. A "variant"
shared library has a non-default SONAME, and non default symbol
versions. This makes it possible to build (say) an OpenSSL 1.1.0
library that can coexist without conflict in the same process address
space as the system's default OpenSSL library which may be OpenSSL
1.0.2.
Such "variant" shared libraries make it possible to link applications
against a custom OpenSSL library installed in /opt/openssl/1.1 or
similar location, and not risk conflict with an indirectly loaded
OpenSSL runtime that is required by some other dependency.
Variant shared libraries have been fully tested under Linux, and
build successfully on MacOS/X producing variant DYLD names. MacOS/X
Darwin has no symbol versioning, but has a non-flat library namespace.
Variant libraries may therefore support multiple OpenSSL libraries
in the same address space also with MacOS/X, despite lack of symbol
versions, but this has not been verified.
Variant shared libraries are optional and off by default.
Reviewed-by: Richard Levitte <levitte@openssl.org>
HP-UX make doesn't recognize $< in explict target rules, only in
inference ones such as .c.o.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4697)
It turns out that (some?) fuzzers can read a dictionary of OIDs,
so we generate one as part of the usual 'make update'.
Fixes#4615
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/4637)
RESULT_D can be used to provide a separate directory for test results.
Let's use that to separate them from other files.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4507)
We changed directory to the wrong directory.
This change also separates the preparation phase from the tarball
building phase.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4179)
submodules are directories that we don't want in our tarballs, so
avoid them.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4178)
$(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)
Makefile.shared was designed to figure out static library names,
shared library names, library version compatibility, import library
names and the like on its own. This was a design for pre-1.1.0
OpenSSL because the main Makefile didn't have all that knowledge.
With 1.1.0, the situation isn't the same, a lot more knowledge is
included in the main Makefile, and while Makefile.shared did things
right most of the time (there are some corner cases, such as the
choice of .sl or .so as DSO extension on some HPUX versions), there's
still an inherent fragility when one has to keep an eye on
Makefile.shared to make sure it produces what the main Makefile
produces.
This change simplifies Makefile.shared by removing all its
"intelligence" and have it depend entirely on the input from the main
Makefile instead. That way, all the naming is driven from
configuration data.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3983)
This new target is used to build all generated files and only that.
This can be used to prepare everything that requires things like perl
for a system that lacks perl and then move everything to that system
and do the rest of the build there.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3695)
Because apps/progs.h isn't configuration agnostic, it's not at all
suited for 'make update' or being versioned, so change it to be
dynamically generated.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3688)
Fix test for "documenting private functions"
And add -p flag to doc-nits recipe
Mark when things were deprecated, if doc'd as such
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3624)
Run perltidy on util/mkerr
Change some mkerr flags, write some doc comments
Make generated tables "const" when genearting lib-internal ones.
Add "state" file for mkerr
Renerate error tables and headers
Rationalize declaration of ERR_load_XXX_strings
Fix out-of-tree build
Add -static; sort flags/vars for options.
Also tweak code output
Moved engines/afalg to engines (from master)
Use -static flag
Standard engine #include's of errors
Don't linewrap err string tables unless necessary
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3392)
Add 2017 copyright year
Add missing typedef to NAME
Remove ec(7) and bn(7) doc links
Remove .pod link errors, bogus links, make a few typo corrections
Fix some typo's in links and some missing items.
Don't link to C runtime functions (See OPENSSL_malloc for example/precedent)
Document ASN1_tag2str(), add a few typedef's that were missing from NAME
Update doc-nits target; addresses
https://github.com/openssl/openssl/pull/1900#issuecomment-259943891,
Merge check-doc-links into find-doc-nits; if run regularly, would have found
https://github.com/openssl/openssl/pull/2825
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2862)
Very simply, support having the .a extension to denote depending on
static libraries. Note that this is not supported on native Windows
when building shared libraries, as there is not static library then,
just an import library with the same name.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1889)
For consistency, it's better to use the perl that was specified to
Configure last time it was called.
Use case:
perl v5.8.8 was first along $PATH, perl v5.22.2 was available and
specified as: PERL=/opt/local/bin/perl ./config. When make wanted to
reconfigure and called './Configure reconf', configuration broke down,
complaining about a perl that's too old.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1884)
Pre 1.1.0, 'make test' would set the environment variable
OPENSSL_DEBUG_MEMORY to "on". This got lost when translating the old
build files to the new templates. This changes reintroduces that
variable.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1840)
