msbuild was complaining that with warning MSB8012 that |TargetPath|
does not match the Linker's OutputFile property value. The problem
was caused by the wrong ordering of the setting of build properties
and the inclusion of the built-in property sheets.
Make default warnings stricter in mk/top_of_makefile.mk, and then
disable the extra warnings as necessary in mk/ring.mk, in order to sync
ring's build system with mozilla::pkix's build system. Also, use spaces
consistently for indention, instead of a mix of spaces and tabs.
It would be nice to keep the one-shot functions around since they are
convenient, but there's not any good, backward-compatible, way to
remove the shared static buffer option. In particular, there are likely
to be many callers of these functions that expect them to never fail,
and so returning |NULL| when the caller doesn't supply a buffer is not
likely to work well in all cases. Consequently, it's better to fail
hard at build time.
The change to add explicitly-deleted constructors and assignemnt
operators in aead_test.cc and digest_test.cc broke GCC 4.8 builds.
Those changes were made to prevent MSVC from issuing these warnings:
* C4623: default constructor was implicitly defined as deleted
because a base class default constructor is inaccessible or
deleted.
* C4626: assignment operator was implicitly defined as deleted
because a base class assignment operator is inaccessible or
deleted.
* C5027: move assignment operator was implicitly defined as deleted
because a base class move assignment operator is inaccessible
or deleted.
All of these warnigns are just "Warning: we didn't do something
impossible in violation of the C++ language semantics" so they are safe
to disable. Even without considering the GCC 4.8 breakage, this is a
better fix.
* Silence some warnings about things that MSVC 2015 warns about that
MSVC 2013 didn't.
* Change the solution so that it opens in Visual Studio 2015 if Visual
Studio 2015 is installed.
* Change ToolsVersion to 14.0 in the project files so that Visual
Studio 2015 does not put a warning in the build log about the version
being 12.0. This means that Visual Studio 2013 will have a warning,
but the warning is harmless, and if we have to choose, it's better
for VS 2013 to warn than VS 2015 to warn, in the long term. See
https://github.com/Microsoft/msbuild/issues/52#issuecomment-88674094.
* Build with the VS 2013 XP-compatible toolchain if using Visual Studio
2013 (including its msbuild); Otherwise build with the Visual Studio
2015 XP-compatible toolchain. See
https://social.msdn.microsoft.com/Forums/vstudio/en-US/ \
d06c3741-c637-4627-9b1a-1e068803a067/ \
setting-platformtoolset-value-based-on-vs-version.
Previously, sha-x86_64.pl (was sha512-x86_64.pl) was used to generate
both sha256-x86_64.S and sha512-x86_64.S. This required special build
logic in ring.mk and also would have required special logic in the
msbuild project files. This commit adds dedicated perlasm source files
for both, and there's now a 1-to-1 correspondence between perlasm
scripts and output files, which avoids any need for special-case logic
in the build system.
The same goes for sha-armv8.pl (was sha512-armv8.pl).
This commit prepares for the addition of dedicated
sha256-{x86_64,armv8}.pl and sha512-{x86_64,armv8}.pl scripts, in order
to create a 1-to-1 mapping of source .pl scripts to generated
.S assembly language files. This is a separate commit so that git tools
recognize the renames correctly.
Much of the repetitive logic was put into mk/Common.props,
mk/Windows.props, and mk/WindowsTest.props. There is still a lot of
repetitive logic in the test project files that should be moved to
WindowsTest.props in the future. (In fact, it would be better if the
build system were modified in the future to work like CMake does,
(re-)generating the necessary project files during the build.)
Regular (OPENSSL_NO_ASM) mode will come in a later commit.
I've marked the Visual Studio files as eol=crlf in .gitattributes for
now. This should be the least painful option, since it any CRLF
conversion would create problems for for people sharing a source tree
across platforms (e.g. a shared folder in a VM), and because Visual
Studio IDE resets the files back to CR/LF line endings whenever a
change to project or solution settings is made using its GUI. There is
no license comment in these files because Visual Studio strips comments
when changes are made using the GUI.
Travis CI doesn't have a new enough version of CMake readily available,
and I've been wanting to replace the CMake-based build system for other
reasons. This kills the Windows support, but I'm intending to add a
native msbuild build system for Windows soon. Also, this builds in
OPENSSL_NO_ASM mode for now.
Eliminate the unnecessary parts of obj_mac.h and put the remainder into
logical order. Remove all the crypto/obj stuff, which was used
primarily by the already-removed crypto/asn1.
Unfortunately these are all too tangled together to remove them
piece-by-piece without creating hard-to-review intermediate changes,
so this commit removes them all at once.
When building in OPENSSL_NO_ASM mode, MSVC complains about unreachable
code. The redundant initialization of |i| is the main problem, but the
the skipping of the first test of the condition |i < num| was also
confusing, so this commit changes the for loop to a do...while loop.
