We had updates of certain header files in both Makefile.org and the
Makefile in the directory the header file lived in. This is error
prone and also sometimes generates slightly different results (usually
just a comment that differs) depending on which way the update was
done.
This removes the file update targets from the top level Makefile, adds
an update: target in all Makefiles and has it depend on the depend: or
local_depend: targets, whichever is appropriate, so we don't get a
double run through the whole file tree.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 0f539dc1a2)
Conflicts:
Makefile.org
apps/Makefile
test/Makefile
Pull constant-time methods out to a separate header, add tests.
Reviewed-by: Bodo Moeller <bodo@openssl.org>
(cherry picked from commit 9a9b0c0401)
Conflicts:
test/Makefile
using OBJ xref utilities instead of string comparison with OID name.
This removes the arbitrary restriction on using SHA1 only with some ECC
ciphersuites.
Add static build support to openssl utility.
Add new "fips" option to Configure.
Make use of installed fipsld and fips_standalone_sha1
Initialise FIPS error callbacks, locking and DRBG.
Doesn't do anything much yet: no crypto is redirected to the FIPS module.
Doesn't completely build either but the openssl utility can enter FIPS mode:
which doesn't do anything much either.
Submitted by: "Green, Paul" <Paul.Green@stratus.com>
Approved by: steve@openssl.org
Fixes to --with-zlib-include and --with-zlib-lib and init PRNG for VOS.
was not executed. It doesn't excuse user from running 'make clean', it
simply avoids process table exhaustion.
PR: 1236
Submitted by: Michael Richardson
- eliminate ambiguities between GNU-ish and SysV-ish make flavors;
- switch [back] to -e;
- fold/unify rules;
This is follow-up to the patch introducing common BUILDENV. Idea is
to collect as much parameters in $(TOP) as possible and "strip" lower
Makefiles for most variables [and thus makes them more readable].
compiled into *our* aplpications. That's because mingw is always
consistent with itself. Having library-side code linked into .dll
makes it possible to deploy the .dll with user-code compiled with
another compiler [which is pretty much the whole point behind Applink].
