test/GNUmakefile: added architecture autodetection; added switches to
CFLAGS and RCFLAGS to make sure that the right architecture is used.
Added support to build with WinCNG.
Added architecture autodetection; added switches to CFLAGS and
RCFLAGS to make sure that the right architecture is used.
Added support to build with WinCNG.
Initially reported by Bob Kast as "for MS VS builds, specify the
libraries that are required so they don't need to go into all
project files that may use this library". Thanks a lot.
If you are building a DLL, then you need to explicitly export each
entry point. When building a static library, you should not.
libssh2 was exporting the entry points whether it was building a DLL or a
static library. To elaborate further, if libssh2 was used as a static
library, which was being linked into a DLL, the libssh2 API would be
exported from that separate DLL.
This avoids line-wrapping in between parameters and makes the
error message look like the following:
configure: error: No crypto library found!
Try --with-libssl-prefix=PATH
or --with-libgcrypt-prefix=PATH
or --with-wincng on Windows
Initially reported by Bob Kast as "Wincng - define function
prototypes for wincng routines". Thanks a lot.
Also replaced structure definitions with type definitions.
Inspired by Bob Kast's reports, this commit enables the compilation
of libssh2 with WinCNG using the generated Visual Studio project files.
This commit adds WinCNG support to parts of the existing Win32 build
infrastructure, until new build systems, like pre-defined VS project
files or CMake files may be added.
This commit and b20bfeb3e5 raise one
question: How to handle build systems, like VS project files, that
need to include all source files regardless of the desired target,
including all supported crypto backends? For now the mentioned commit
added a check for LIBSSH2_OPENSSL to openssl.c and with this commit
the supported crypto backends are hardcoded within Makefile.am.
Removed header file combination that is not supported on a real
Windows platform and can only be compiled using MinGW. Replaced
custom NTSTATUS return code checks with BCRYPT_SUCCESS macro.
../src/knownhost.c: In function 'libssh2_knownhost_readline':
../src/knownhost.c:651:16: warning: 'key_type_len' may be used
uninitialized in this function [-Wmaybe-uninitialized]
rc = knownhost_add(hosts, hostbuf, NULL,
^
../src/knownhost.c:745:12: note: 'key_type_len' was declared here
size_t key_type_len;
^
Commit d512b25f69 introduced a crypto
library abstraction in the autotools build system, to allow us to more
easily support new crypto libraries. In that process it was found that
all other build system which we support are hard-coded to build with
OpenSSL. Commit f5c1a0d98b fixes automake
introduced into non-autotools build systems but still overlooked the
CPP macro saying that we are using OpenSSL.
Thanks to Marc Hörsken for identifying this issue and proposing a fix
for win32/{GNUmakefile,config.mk}. This commit uses a slightly different
approach but the end result is the same.
Commit 85c6627c changed the behaviour of `libssh2_knownhost_writeline` so that it stopped returning the number of bytes needed when the given buffer was too small. Also, the function changed such that is might write to part of the buffer before realising it is too small.
This commit restores the original behaviour, whilst keeping the unknown-key-type functionality that 85c6627c. Instead of writing to the buffer piecemeal, the length of the various parts is calculated up front and the buffer written only if there is enough space. The calculated necessary size is output in `outlen` regardless of whether the buffer was written to.
The main use-case for the original behaviour that this commit restores is to allow passing in a NULL buffer to get the actual buffer size needed, before calling the function again with the buffer allocated to the exact size required.
