Issue: #2575
Build instructions for OpenBSD 6.2:
* boost (built with clang)
* cppzmq
Fixed a issue, where cmake was not able to find and link against libressl in unbound.
restored OpenBSD 5.8 build instructions
These files were pulled from the 1.6.3 release tarball.
This new version builds against OpenSSL version 1.1 which will be
the default in the new Debian Stable which is due to be released
RealSoonNow (tm).
EVP_dss1() was deprecated and EVP_sha1() is the direct replacement.
Upstream libunbound already has this patch. Note that I haven't
added a test for HAVE_EVP_DSS1 since that was deprecated quite a
long time ago in OpenSSL, there's really no reason to support it.
Keep the immediate direct deps at the library that depends on them,
declare deps as PUBLIC so that targets that link against that library
get the library's deps as transitive deps.
Break dep cycle between blockchain_db <-> crytonote_core.
No code refactoring, just hide cycle from cmake so that
it doesn't complain (cycles are allowed only between
static libs, not shared libs).
This is in preparation for supproting BUILD_SHARED_LIBS cmake
built-in option for building internal libs as shared.
The split is to make this software more packageable. 'make install'
is used by the package building scripts, and should not be installing
vendored dependencies onto the system.
Using libevent seems to have high peaks of file descriptor use,
which can cause failure to create fds in other parts of bitmonerod.
The fallback implementation seems to run fine in a significantly
tighter file descriptor limit.
Due to a bug in unbound, we were passing a string containing a null
character to ub_ctx_resolvconf and ub_ctx_hosts rather than a NULL
pointer. On *nix this wasn't causing headache, but on Windows this was
causing unbound to not correctly load DNS settings from the OS.
Note on the bug: in a Windows-specific code branch in the function
ub_ctx_hosts(), if the hosts file specified was a NULL pointer, a call
to getenv() was stored in a local char* and later freed. This is
incorrect, as we do not own that data, and caused the program to crash.
On Windows, getaddrinfo is part of the Windows API and as such is
__stdcall, not __cdecl, so check_function_exists fails because the
declaration doesn't match the mangling __stdcall has. Instead, use a
header to include the symbol as declared on the system and use
check_symbol_exists instead.
Tested-By: greatwolf on IRC