* Problem: In rare cases, afunix.h doesn't contain a definition for struct sockaddr_un
According to https://github.com/microsoft/vcpkg/issues/21623,
struct sockaddr_un might be unavailable on some machines even afunix.h exists.
For example, on some machines, the content of afunix.h looks like this:
typedef struct _SOCKADDR_UN
{
ADDRESS_FAMILY Family;
wchar_t Path[63];
} SOCKADDR_UN, *PSOCKADDR_UN;
but on other machines, it may looks like this:
#define UNIX_PATH_MAX 108
typedef struct sockaddr_un
{
ADDRESS_FAMILY sun_family;
char sun_path[UNIX_PATH_MAX];
} SOCKADDR_UN, *PSOCKADDR_UN;
Fixes#3949
References:
- [Enable Unix-domain sockets support on Windows](8f3ec75de4)
- [AF_UNIX equivalent for Windows](https://stackoverflow.com/questions/9029174/af-unix-equivalent-for-windows)
- https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/
Solution: add a preprocessor variable ZMQ_NO_EXPORT that, when set, bypasses the automatic ZMQ_EXPORT determination block and just sets ZMQ_EXPORT to empty.
By combining this solution at configuration time with manually passing -fvisibility=hidden to CXXFLAGS, I solved my visibility problem. Just passing -fvisibility=hidden is not enough, because __attribute__ ((visibility ("default"))) has higher priority.
zmq_ppoll mostly mimics zmq_poll behavior, except for the added feature of being able to specify a signal mask. Signals in this mask will be blocked during execution of zmq_ppoll. Switching of the process' active signal mask happens atomically with the actual poll call, so that no race conditions can occur. This behavior is useful when one wants to gracefully handle POSIX signals without race conditions. See e.g. the discussion below https://250bpm.com/blog:12/ for an explanation.
Also includes two new tests:
1. test_zmq_ppoll_fd does the same thing as test_zmq_poll_fd, demonstrating backwards compatibility with zmq_poll when used with a default signal mask.
2. test_zmq_ppoll_signals demonstrates the use of zmq_ppoll with a signal mask, blocking out SIGTERM everywhere except in zmq_ppoll, allowing to handle the signal in one place without having to worry about race conditions.
* add opt-out for randombytes_close
Problem: randombytes_close is either a no-op or unsafe when a Context is running.
Unfortunately, there does not appear to be a single always correct choice,
so let builders pick between two not-great options.
Opting out can leak an FD on /dev/urandom which may need to be closed explicitly.
However, with the default behavior,
using multiple contexts with CURVE can crash with no application-level workaround available.
randombytes_close is not threadsafe and calling it while still in use by a Context can cause a crash.
For implementations using /dev/[u]random, this can leave up to one leftover FD per process.
The libsodium docs suggest that this function rarely needs to be called explicitly.
If you cloned and built this repo or built it from a submodule, it
would always report "Build and install draft classes and methods"
which first might be wrong if ENABLE_DRAFTS is OFF but also didn't
match the tense of other similar messages about build options.
Retain GNU extensions for C99 and C++98 since testing old compilers
is especially difficult and these compilation modes exist to maintain
compatability.
* Problem: No direct support for setting socket priority
Solution: Add ZMQ_PRIORITY socket option, which sets the
SO_PRIORITY socket option on the underlying socket. This
socket option is not supported under Windows. Check option
and set socket option on creation of underlying socket.
Don't include bsd/string.h if strlcpy is also defined in string.h to
avoid the following build failure on uclibc:
In file included from src/compat.hpp:41:0,
from src/ipc_address.cpp:31:
/tmp/instance-0/output-1/host/mips64el-buildroot-linux-uclibc/sysroot/usr/include/bsd/string.h:44:54: error: declaration of 'size_t strlcpy(char*, const char*, size_t)' has a different exception specifier
size_t strlcpy(char *dst, const char *src, size_t siz);
^
In file included from src/compat.hpp:34:0,
from src/ipc_address.cpp:31:
/tmp/instance-0/output-1/host/mips64el-buildroot-linux-uclibc/sysroot/usr/include/string.h:424:15: error: from previous declaration 'size_t strlcpy(char*, const char*, size_t) throw ()'
extern size_t strlcpy(char *__restrict dst, const char *__restrict src,
^
Fixes:
- http://autobuild.buildroot.org/results/51220b1b82774e8f6f6ed8593c58d2e3c31a1531
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
* apply the use of sources for xcode project also to dynamic library
Co-authored-by: Stéphane Valès <stephane@vales.fr@users.noreply.github.com>
Co-authored-by: stephane vales <vales@ingenuity.io>
* use sources instead of objects only when generating an xcode project
Co-authored-by: Stéphane Valès <stephane@vales.fr@users.noreply.github.com>
Co-authored-by: stephane vales <vales@ingenuity.io>
* Allow CMAKE to generate ws and wss transports
I guess there is little use of just ws transport, so by default
GnuTLS (and libsodium) are enabled
* cmake libzmq including wss transport (ubuntu 19.10 and ubuntu 19.10 + wsl 1.0)
test_security_fails (libsodium assert !?)
* updated relicense
* make external libs gnutls nss sodium optional
* #ifdef WSS classes and functions, build test*ws* only if correct libs are included, warning if libs not present
* make libsodium optional
* cmake fix tests TIPC transport
* clang-format pointed out a wrongly placed #ifdef
* GnuTLS before 3.6.7 is not safe
* msvc doesn't agree with strlen in array declaration, test_socks now at least compiles on windows
* windows: libsodium build fails, missing include dirs set by env var
* ws transport test only works when GnuTLS is found
* Fixed condition to use NSS / built in SHA1, so that test_ws_transport should now pass, also when GnuTLS is not found
Solution: Install CMake config in arch-dependent LIBDIR/cmake
Using "share/cmake/${PROJECT_NAME}" as DESTINATION for installing
ZeroMQConfig.cmake et al works for arch-independent configs, but
is wrong for multiarch. The configs for each version of the
library should be stored below the arch-dependent LIBDIR, using
the GNUInstallDirs ${CMAKE_INSTALL_LIBDIR} variable.
Signed-off-by: FeRD (Frank Dana) <ferdnyc@gmail.com>
Solution: a new socket type, called PEER. Very similar to SERVER, but can only connect to other PEERs. Also a new zmq_connect_peer method, that connect and return a routing-id in thread-safe and atomic operation
Solution: if all peers of a socket are >= 3.1 use sub/cancel commands
instead of the old 0/1 messages.
For backward compatibility, move the handling of 0/1 or sub/cancel
command strings to the encoders, so that the right thing can be done
depending on the protocol version.
Do not set the command flag until the encoder, so that we can handle
the inproc case (which skips the encoder).
Solution: use libbsd by default when available, and the internal implementation
only as a fallback, to take advantage of Linux distros maintenance of the
string libraries.
* Problem: if IPC enabled libzmq does not compile when in uwp build
* Problem 10.0.##### can be valid windows target versions
* Problem: No builds are triggered on uwp platform
* Problem: epoll is set before UWP platform is checked
* Problem: used wrong CMAKE_SYSTEM_NAME specifier
* Problem: build tests fails during cmake configure
* Use Win32 build step for Win32-uwp platform
* Disable compile options that produce warnings that leads to a ci fail
* winnt version is set by cmake, no need for redefinition in windows.hpp
* Eliminate all warning according Incremental and opt:icf are specified
* Prefer to disable opt flags in debug config rather than incremental linking
* CMAKE_GENERATOR should not include uwp definition
* Add release build with uwp configuration
* Problem: pointer potentially uninitialized
On MinGW, librt will might will found as rt library in MSYS, but fails linking with "cannot find -lrt" error.
As librt is not avaiable on native Windows, we should never try to link with -lrt on MinGW (which is native Windows).
Improve performance of the proxy forwarding batch of message.
Add throughput benchmark for proxy.
Fix valgrind error reported on unitialized vars
RELICENSE: Add emtr grant
Solution: calculate from CMAKE_SYSTEM_VERSION
Problem: CMAKE_SYSTEM_VERSION might be newer than Windows SDK Version
Solution: limit _WIN32_WINNT value to Visual Studio default Windows SDK version
Solution: detect cacheline size for aligment purposes at build time
instead of hard-coding it, so that PPC and S390 can align to a value
greater than the 64 bytes default.
Uses libc getconf program, and falls back to the previous value of 64
if not found.
Solution: use requires.private, which pkg-config expands recursively
so that dependencies of dependencies can be linked against when
using pkg-config --static
- MacOS version requires CMake version 3.0.2 (because of policy CMP0042)
- Add option to build instrumented binaries with Address Sanitizer
- Add option to select compiler intrinsics for atomic ops
- Only build docs on request (saves build time)
- Lowercase all commands
- Unify indent to 2 spaces
- Remove spaces around brackets
- Remove repitition of condition in else(...) and endif(...)
Note: (re-)running CMake did not change the content of the generated files
* Problem: No CI for mingw64
Adding CI support for mingw64 to appveyor.yml
Reason: To help address the issue:
Several checks fail under 64-bit MinGW on Windows when running make check #3185
* Problem: Docs do not build with mingw64, dll already in right place
Turning off WITH_DOC for mingw64
Removing copy command for mingw64 and cygwin64 (it now seems to be directly built in "bin" directoy)
Solution: Use cmake's libdir variable to ensure that the pkgconfig file
ends up in the correct lib/lib64 directory. This matches the autotools
behaviour.
