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

Borland C++ 4.5 is very old and our "support" for it is already
non-existent, we might as well remove it.
Reviewed-by: NRich Salz <rsalz@openssl.org>

When building the DLLs, we depend on the correct default C RTL info.
Reviewed-by: NMatt Caswell <matt@openssl.org>

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

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

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

Reviewed-by: NAndy Polyakov <appro@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>

When object files with common block symbols are added to static
libraries on Darwin, those symbols are invisible to the linker that
tries to use them.  Our solution was to use -fno-common when compiling
C source.

Unfortunately, there is assembler code that defines OPENSSL_ia32cap_P
as a common block symbol, unconditionally, and in some cases, there is
no other definition.  -fno-common doesn't help in this case.

However, 'ranlib -c' adds common block symbols to the index of the
static library, which makes them visible to the linker using it, and
that solves the problem we've seen.

The common conclusion is, either use -fno-common or ranlib -c on
Darwin.  Since we have common block symbols unconditionally, choosing
the method for our source is easy.
Reviewed-by: NKurt Roeckx <kurt@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>

This has no real meaning, except it gives Configure a hint that VC
targets are indeed capable of producing shared objects.
Reviewed-by: NMatt Caswell <matt@openssl.org>

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

Since the configs were remade into hash tables, this isn't needed
any more.
Reviewed-by: NRich Salz <rsalz@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>

These flags are limitting needlessly, are often patched by packagers,
and should be specified on the configuration command line by anyone
who desires for it to be specific rather than forced by us.

This work was already done with mingw when those configs were worked
on, now it gets applied to the remaining configs.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

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

One spot was forgotten.
Reviewed-by: NRich Salz <rsalz@openssl.org>

So far, MingW shared libraries were named like this

  libeay32.dll + libeay32.dll.a
  ssleay32.dll + ssleay32.dll.a

That naming scheme is antiquated, a reminicense of SSLeay.  We're
therefore changing the scheme to something that's more like the rest
of OpenSSL.

There are two factors to remember:

  - Windows libraries have no recorded SOvers, which means that the
    shared library version must be encoded in the name.  According to
    some, it's unwise to encode extra periods in a Windows file name,
    so we convert version number periods to underscores.
  - MingW has multilib ability.  However, DLLs need to reside with the
    binaries that use them, so to allow both 32-bit and 64-bit DLLs to
    reside in the same place, we add '-x64' in the name of the 64-bit
    ones.

The resulting name scheme (for SOver 1.1) is this:

  on x86:
  libcrypto-1_1.dll + libcrypto.dll.a
  libssl-1_1.dll + libssl.dll.a

  on x86_64:
  libcrypto-1_1-x64.dll + libcrypto.dll.a
  libssl-1_1-x64.dll + libssl.dll.a

An observation is that the import lib is the same for both
architectures.  Not to worry, though, as they will be installed in
PREFIX/lib/ for x86 and PREFIX/lib64/ for x86_64.

As a side effect, MingW got its own targets in Makefile.shared.
link_dso.mingw-shared and link_app.mingw-shared are aliases for the
corresponding cygwin-shared targets.  link_shlib.mingw-shared is,
however, a target separated from the cygwin one.
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>

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

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

The reason is that we use hstrerror() and other resolver functions.

Reporter: Erik Forsberg <erik@efca.com>
Reviewed-by: NRich Salz <rsalz@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>

Add utility macros REF_ASSERT_NOT and REF_PRINT_COUNT
This is also RT 4181
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

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

As part of this, change util/mkdef.pl to stop adding libraries to
depend on in its output.  mkdef.pl should ONLY output a symbol
vector.

Because symbol names can't be longer than 31 characters, we use the
compiler to shorten those that are longer down to 23 characters plus
an 8 character CRC.  To make sure users of our header files will pick
up on that automatically, add the DEC C supported extra headers files
__decc_include_prologue.h and __decc_include_epilogue.h.

Furthermore, we add a config.com, so VMS people can configure just as
comfortably as any Unix folks, thusly:

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

Cygwin and Mingw name their libraries a bit differently from the rest
of the POSIXly universe, we need to adapt to that.

In Makefile.tmpl, it means that some hunks will only be output
conditionally.

This also means that shared_extension for the Cygwin and Mingw
configurations in Configurations/10-main.conf are changing from .dll.a
to .dll.  Makefile.shared does a fine job without having them
specified, and it's much easier to work with tucking an extra .a at
the end of files in the installation recipes than any amount of name
rewrites, especially with the support of the SHARED_NAME in the top
build.info.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Some time ago, we had a ex_libs configuration setting that could be
divided into lflags and ex_libs.  These got divided in two settings,
lflags and ex_libs, and the former was interpreted to be general
linking flags.

Unfortunately, that conclusion wasn't entirely accurate.  Most of
those linking were meant to end up in a very precise position on the
linking command line, just before the spec of libraries the linking
depends on.

Back to the drawing board, we're diving things further, now having
lflags, which are linking flags that aren't depending on command line
position, plib_lflags, which are linking flags that should show up just
before the spec of libraries to depend on, and finally ex_libs, which
is the spec of extra libraries to depend on.

Also, documentation is changed in Configurations/README.  This was
previously forgotten.
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

The lflags configuration had a weird syntax with a % as separator.  If
it was present, whatever came before ended up as PEX_LIBS in Makefile
(usually, this is LDFLAGS), while whatever came after ended up as
EX_LIBS.

This change splits that item into lflags and ex_libs, making their use
more explicit.

Also, PEX_LIBS in all the Makefiles are renamed to LDFLAGS.
Reviewed-by: NRich Salz <rsalz@openssl.org>

A few more sub-joins could be replaced with calls to add() and add_before()
Reviewed-by: NRich Salz <rsalz@openssl.org>

This is a followin from !1738, we no longer need those variables.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Many options for supporting optimizations for legacy crypto on legacy
platforms have been removed.  This simplifies the source code and
does not really penalize anyone.
        DES_PTR (always on)
        DES_RISC1, DES_RISC2 (always off)
        DES_INT (always 'unsigned int')
        DES_UNROLL (always on)
        BF_PTR (always on) BF_PTR2 (removed)
        MD2_CHAR, MD2_LONG (always 'unsigned char')
        IDEA_SHORT, IDEA_LONG (always 'unsigned int')
        RC2_SHORT, RC2_LONG (always 'unsigned int')
        RC4_LONG (only int and char (for assembler) are supported)
        RC4_CHUNK (always long), RC_CHUNK_LL (removed)
        RC4_INDEX (always on)
And also make D_ENCRYPT macro more clear (@appro)

This is done in consultation with Andy.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Time to get rid of @MK1MF_Builds and introduce a more flexible
'build_scheme' configuration key.  Its value may be a string or an
array of strings, meaning we need to teach resolve_config how to
handle ARRAY referenses.

The build scheme is a word that selects a function to create the
appropriate result files for a certain configuration.  Currently valid
build schemes aer "mk1mf" and "unixmake", the plan is however to add
at least one other for a more universal build scheme.

Incidently, this also adds the functions 'add' and 'add_before', which
can be used in a configuration, so instead of having to repeatedly
write a sub like this:

	key1 => sub { join(" ", @_, "myvalues"); },
	key2 => sub { join(" ", "myvalues", @_); },

one could write this:

	key1 => add(" ", "myvalues"),
	key2 => add_before(" ", "myvalues"),

The good point with 'add' and 'add_before' is that they handle
inheritances where the values are a misture of scalars and ARRAYs.  If
there are any ARRAY to be found, the resulting value will be an ARRAY,
otherwise it will be a scalar with all the incoming valued joined
together with the separator given as first argument to add/add_before.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Cygwin was used for x86 before, so let's keep it around for those who
still use it (it make Configure reconf possible).
Cygwin-i[3456]86 for those that might generate and pass a target name
directly to Configure.
Reviewed-by: NRich Salz <rsalz@openssl.org>

This is to reflect that it's not limited to just i686.
Reviewed-by: NRich Salz <rsalz@openssl.org>