When compiling all other C files, rely on the compiler to
automatically pick up the name translation information from the header
files __DECC_INCLUDE_{PRO,EPI}LOGUE.H.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

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

This also restores the possibility to have ml used with VC-WIN32 with
no-asm, which was lost during the mk1mf -> unified transition.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

* add a comment about Haiku being built with no-asm.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

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

Instead of absolute hard coding of the libz library name, have it use
the macro LIBZ, which is set to defaults we know in case it's
undefined.

This allows our configuration to set something that's sane on current
or older platforms, and allows the user to override it by defining
LIBZ themselves.
Reviewed-by: NMatt Caswell <matt@openssl.org>

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>

Since NDEBUG is defined unconditionally on command line for release
builds, we can omit *_DEBUG options in favour of effective "all-on"
in debug builds exercised though CI.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

... and refine /MT vs. /MD flag handling.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reverts commit 087ca80a

Instead of battling the odd format of argv given to main() in default
P64 mode, tell the compiler to make it an array of 64-bit pointers
when compiling in P64 mode.

A note is added in NOTES.VMS regarding minimum DEC C version.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

"vms-generic" already has some values, which were discarded.
Reviewed-by: NRich Salz <rsalz@openssl.org>

The warning MAYLOSEDATA3 is one you will always get when compiling
source that calculates the difference between two pointers with
/POINTER_SIZE=64.

The reason is quite simple, ptrdiff_t is always a 32-bit integer
regardless of pointer size, so the result of 'ptr1 - ptr2' can
potentially be larger than a 32-bit integer.  The compiler simply
warns you of that possibility.

However, we only use pointer difference within objects and strings,
all of them well within 2^32 bytes in size, so that operation is
harmless with our source, and we can therefore safely turn off that
warning.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

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

- VMS configs had no dso_scheme
- Incorrect return of NULL method.
Reviewed-by: NTim Hudson <tjh@openssl.org>

On VMS, we downcase option names, which means that config names are
downcased as well, so they need to be downcased in the target table to
be found.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

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

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

utils/mkrc.pl was added a while ago as a better generator for the
Windows DLL resource file.  Finalize the change by removing the
ms/version32.rc generator from Configure and adding resource file
support using mkrc.pl in Configurations/windows-makefile.pl
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Document them as well
Reviewed-by: NAndy Polyakov <appro@openssl.org>

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

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>