Dependencies such as cURL and OpenSSL are necessary to build and run
Git. Previously, we obtained those dependencies by fetching NuGet
packages.
However, it is notoriously hard to keep NuGet packages of C/C++
libraries up-to-date, as the toolsets for different Visual Studio
versions are different, and the NuGet packages would have to ship them
all.
That is the reason why the NuGet packages we use are quite old, and even
insecure in the case of cURL and OpenSSL (the versions contain known
security flaws that have been addressed by later versions for which no
NuGet packages are available).
The better way to handle this situation is to use the vcpkg system:
https://github.com/Microsoft/vcpkg
The idea is that a single Git repository contains enough supporting
files to build up-to-date versions of a large number of Open Source
libraries on demand, including cURL and OpenSSL.
We integrate this system via four new .bat files to
1) initialize the vcpkg system,
2) build the packages,
4) set up Git's Makefile system to find the build artifacts, and
3) copy the artifacts into the top-level directory
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Install required third-party DLLs next to EXEs.
Build and install release mode PDBs for git
executables allowing detailed stack traces
in the event of crash.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Support -Z flags ("specify PDB options"), only include -l args on link
commands, and force PDBs to be created.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Teach the clink.pl script that -lcurl is a request to link with the
cURL library, and drop NO_CURL from config.mak.uname for the MSVC
platform.
Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows the convention is to rely on filename extensions to decide
whether a file is executable so Windows users are probably not relying
on the executable bit of these scripts, but on other platforms it can
be useful documentation.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Having recently added support for building git-imap-send on
Windows, we now link against OpenSSL libraries, and the linker
issues the following warning:
warning LNK4044: unrecognized option '/lssl'; ignored
In order to suppress the warning, we change the msvc linker
script to translate an '-lssl' parameter to the ssleay32.lib
library.
Note that the linker script was already including ssleay32.lib
(along with libeay32.lib) as part of the translation of the
'-lcrypto' library parameter. However, libeay32.dll does not
depend on ssleay32.dll and can be used stand-alone, so we remove
ssleay32.lib from the '-lcrypto' translation.
The dependence of ssleay32.dll on libeay32.dll is represented in
the Makefile by the NEEDS_CRYPTO_WITH_SSL build variable.
Also, add the corresponding change to the buildsystem generator.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ef/msys-imap:
Windows: use BLK_SHA1 again
MSVC: Enable OpenSSL, and translate -lcrypto
mingw: enable OpenSSL
mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
imap-send: build imap-send on Windows
imap-send: fix compilation-error on Windows
imap-send: use run-command API for tunneling
imap-send: use separate read and write fds
imap-send: remove useless uid code
We don't use crypto, but rather require libeay32 and
ssleay32. handle it in both the Makefile msvc linker
script, and the buildsystem generator.
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
During an MSVC build on cygwin, the make program did not notice
when the compiler or linker exited with an error. This was caused
by the scripts exiting with the value returned by system() directly.
On POSIX-like systems, such as cygwin, the return value of system()
has the exit code of the executed command encoded in the first byte
(ie the value is shifted up by 8 bits). This allows the bottom
7 bits to contain the signal number of a terminated process, while
the eighth bit indicates whether a core-dump was produced. (A value
of -1 indicates that the command failed to execute.)
The make program, however, expects the exit code to be encoded in the
bottom byte. Futhermore, it apparently masks off and ignores anything
in the upper bytes.
However, these scripts are (naturally) intended to be used on the
windows platform, where we can not assume POSIX-like semantics from
a perl implementation (eg ActiveState). So, in general, we can not
assume that shifting the return value right by eight will get us
the exit code.
In order to improve portability, we assume that a zero return from
system() indicates success, whereas anything else indicates failure.
Since we don't need to know the exact exit code from the compiler
or linker, we simply exit with 0 (success) or 1 (failure).
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Enable MSVC builds with GNU Make by simply calling
make MSVC=1
(Debug build possible by adding DEBUG=1 as well)
Two scripts, clink.pl and lib.pl, are used to convert certain GCC
specific command line options into something MSVC understands.
By building for MSVC with GNU Make, we can ensure that the MSVC
port always follows the latest code, and does not lag behind due
to unmaintained NMake Makefile or IDE projects.
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
