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)

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

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

It will return the last expression from the input file.

We also use this in read_config, which slightly changes what's
expected of Configurations/*.conf.  They do not have to assign
%targets specifically.  On the other hand, the table of configs MUST
be the last expression in each of those files.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)

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

Remove some incorrect copyright references.
Move copyright to standard place
Add OpenSSL copyright where missing.
Remove copyrighted file that we don't use any more
Remove Itanium assembler for RC4 and MD5 (assembler versions of old and
weak algorithms for an old chip)
Standardize apps/rehash copyright comment; approved by Timo
Put dual-copyright notice on mkcert
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3691)

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

Now that we can link specifically with static libraries, the immediate
need to split ppccap.c (and eventually other *cap.c files) is no more.

This reverts commit e3fb4d3d.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Having that code in one central object file turned out to cause
trouble when building test/modes_internal_test.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1883)

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

[And remove FPU mutiplication subroutine.]
Reviewed-by: NRich Salz <rsalz@openssl.org>

MIPS[32|64]R6 is binary and source incompatible with previous MIPS ISA
specifications. Fortunately it's still possible to resolve differences
in source code with standard pre-processor and switching to trap-free
version of addition and subtraction instructions.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

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

The easiest way to take care of manifest files is to integrate them
into the associated binary (.exe or .dll).  MT (the Manifest Tool) is
the utility to use for this.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

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

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

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

To begin with, the default should have been the import library, not
the DLL itself.  However, we don't know what directory it's installed
in either way, so we may as well demand the full path from the user
Reviewed-by: NMatt Caswell <matt@openssl.org>

The macros ZLIB and ZLIB_SHARED weren't appropriately defined,
deviating wrongly from how they worked in earlier OpenSSL versions.
So, restore it so that ZLIB is defined if configured "enable-zlib" and
so that ZLIB and ZLIB_SHARED are defined if configured
"enable-zlib-dynamic".

Additionally, correct the interpretation of the --with-zlib-lib value
on Windows and VMS, where it's used to indicate the actual zlib
zlib library file / logical name, as that can differ depending on zlib
version and packaging on those platforms.

Finally for Windows and VMS, we also define the macro LIBZ with that
file name / logical name when configured "zlib-dynamic", so the
compression unit can pick it up and use it.
Reviewed-by: NMatt Caswell <matt@openssl.org>

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

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

This introduces the settings loutflag and aroutflag, because different
Windows tools that do the same thing have different ways to specify
the output file.

The Borland C++ config is commented away for the monent, perhaps
permanently.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Make all scripts produce .S, make interpretation of $(CFLAGS)
pre-processor's responsibility, start accepting $(PERLASM_SCHEME).
[$(PERLASM_SCHEME) is redundant in this case, because there are
no deviataions between Solaris and Linux assemblers. This is
purely to unify .pl->.S handling across all targets.]
Reviewed-by: NRichard Levitte <levitte@openssl.org>

For config targets such as 'dist', which doesn't have a BASE template,
we still need to have a default build scheme.

Additionally, the unified Makefile template's target 'tar' wasn't
quite as flexible as the unixmake one.

Finally, .travis-create-release.sh can be somewhat simplified now that
it builds with the unified build scheme.
Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags.  Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.

Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).

Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.

The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config.  Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Instead, make the build type ("debug" or "release") available through
$config{build_type} and let the configs themselves figure out what the
usual settings (such as "cflags", "lflags" and so on) should be
accordingly.

The benefit with this is that we can now have debug and release
variants of any setting, not just those Configure supports, and may
also involve other factors (the MSVC flags /MD[d] and /MT[d] involve
both build type and whether threading is enabled or not)
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Configure had the Unix centric addition of -lz when linking with zlib
is enabled, which doesn't work on other platforms.  Therefore, we move
it to the BASE_unix config template and add corresponding ones in the
other BASE_* config templates.  The Windows one is probably incomplete,
but that doesn't matter for the moment, as mk1mf does it's own thing
anyway.

This required making the %withargs table global, so perl snippets in
the configs can use it.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

These BASE templates are intended to hold values that are common for
all configuration variants for whole families of configurations.

So far, three "families" are identified: Unix, Windows and VMS, mostly
characterised by the build system they currently use.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

There are cases, for example when configuring no-asm, that the added
uplink source files got in the way of the cpuid ones.  The best way to
solve this is to separate the two.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

They now default to " " as separator, but that can be overridden by
having a hash with parameters as last argument.  The only currently
recognised parameter is `separator'.

The special separator `undef' will force the result to become a list
rather than a concatenated string.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Adding uplink and applink to some builds was done by "magic", the
configuration for "mingw" only had a macro definition, the Configure
would react to its presence by adding the uplink source files to
cpuid_asm_src, and crypto/build.info inherited dance to get it
compiled, and Makefile.shared made sure applink.o would be
appropriately linked in.  That was a lot under the hood.

To replace this, we create a few template configurations in
Configurations/00-base-templates.conf, inherit one of them in the
"mingw" configuration, the rest is just about refering to the
$target{apps_aux_src} / $target{apps_obj} in the right places.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

These two functions take a separator to concatenat the strings with as
first argument.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

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

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

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