Trim trailing whitespace. It doesn't match OpenSSL coding standards,
AFAICT, and it can cause problems with git tooling.

Trailing whitespace remains in test data and external source.
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8092)

We never used it for anything
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8125)

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: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8125)

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: NTim Hudson <tjh@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)

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: NTim 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: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7553)

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: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7333)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7277)

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

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

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

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)

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

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

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: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)

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

Similar to commit 17b60280(
"Remove extra `the` in SSL_SESSION_set1_id.pod"), this commit removes
typos where additional 'the' have been added.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4999)

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

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: NRichard Levitte <levitte@openssl.org>

Around 138 distinct errors found and fixed; thanks!
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3459)

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

Fixes GH#3116.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

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

A note: this will form object file names by changing '.cc' to
'_cc.o'.  This will permit other configuration code to recognise these
object files were built for C++ rather than C.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

The Unix build was the last to retain the classic build scheme.  The
new unified scheme has matured enough, even though some details may
need polishing.
Reviewed-by: NRich Salz <rsalz@openssl.org>

There are rare cases when an object file will only be used when
building a shared library.  To enable this, we introduce
SHARED_SOURCE:

    SHARED_SOURCE[libfoo]=dllmain.c
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NAndy Polyakov <appro@openssl.org>

Should it be needed because the recipes within a RAW section might
clash with those generated by Configure, it's possible to tell it
not to generate them with the use of OVERRIDES, for example:

    SOURCE[libfoo]=foo.c bar.c

    OVERRIDES=bar.o
    BEGINRAW[Makefile(unix)]
    bar.o: bar.c
        $(CC) $(CFLAGS) -DSPECIAL -c -o $@ $<
    ENDRAW[Makefile(unix)]
Reviewed-by: NRich Salz <rsalz@openssl.org>

In some cases, one might want to generate some source files from
others, that's done as follows:

    GENERATE[foo.s]=asm/something.pl $(CFLAGS)
    GENERATE[bar.s]=asm/bar.S

The value of each GENERATE line is a command line or part of it.
Configure places no rules on the command line, except the the first
item muct be the generator file.  It is, however, entirely up to the
build file template to define exactly how those command lines should
be handled, how the output is captured and so on.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NAndy Polyakov <appro@openssl.org>

Signed-off-by: NRich Salz <rsalz@akamai.com>
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

This takes us away from the idea that we know exactly how our static
libraries are going to get used.  Instead, we make them available to
build shareable things with, be it other shared libraries or DSOs.

On the other hand, we also have greater control of when the shared
library cflags.  They will never be used with object files meant got
binaries, such as apps/openssl or test/test*.

With unified, we take this a bit further and prepare for having to
deal with extra cflags specifically to be used with DSOs (dynamic
engines), libraries and binaries (applications).
Reviewed-by: NRich Salz <rsalz@openssl.org>

Since we're using the acronym DSO everywhere else and that's a common
name for that kind of object, we might as well do so here as well.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

.d (.MMS in the VMS world) files with just dependencies are built from
exactly the same conditions as the object files.  Therefore, the rules
for them can be built at the same time as the rules for the
corresponding object files.

This removes the requirement for a src2dep function in the build file
templates, and for common.tmpl to call it.  In the end, the existence
of depend files is entirely up to the build file.
Reviewed-by: NRich Salz <rsalz@openssl.org>