Solution: remove implementation. Frank Hartmann <soundart@gmx.net>,
the author, rejected our request to relicense under MPL2, so we
have to remove his copyrighted work.
Tweetnacl is not security-supported and could not be used in
production environments anyway, the supported backend is libsodium.
Solution: When compiling with gcc 7 and newer, the program produced by
AC_CHECK_FUNCS(fork) produces a warning, which results in configure
incorrectly disabling fork support. Fix the issue by using an
AC_COMPILE_IFELSE which correctly detects fork availability.
Tested by running configure and make check on a system with gcc 7
installed, and verifying that HAVE_FORK was defined correctly.
See issue #3313.
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.
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>
Using -Werror has been disabled for Darwin since very early on in the
codebase. However at this point, I can't see an obvious reason why it
should still be disabled compared to when building for the other
operating systems.
I've tested compiling on macOS using Apple Clang 11.0.3, LLVM Clang
10.0.0 and GCC 10.1.
Master doesn't currently compile when crossing compiling using
autotools and mingw-w64. i.e:
```bash
x86_64-w64-mingw32-g++ (GCC) 9.3.0
./autogen.sh
./configure --host=x86_64-w64-mingw32
make src/libzmq.la
....
CXX src/libzmq_la-curve_server.lo
In file included from src/address.cpp:37:
src/ipc_address.hpp:40:10: fatal error: sys/socket.h: No such file or directory
40 | #include <sys/socket.h>
| ^~~~~~~~~~~~~~
compilation terminated.
```
I assume this hasn't been caught because appveyor is using CMake.
Mingw also does not have an afunix.h header. There is a thread upstream,
but there doesn't seem to have been any discussion:
https://sourceforge.net/p/mingw-w64/discussion/723797/thread/4c8ecdbe0d/.
Some compilers, like GCC, will only warn about unknown -Wno-* options
when other warnings are being thrown, i.e:
```bash
CXX src/libzmq_la-address.lo
src/address.cpp: In function 'zmq::zmq_socklen_t zmq::get_socket_address(zmq::fd_t, zmq::socket_end_t, sockaddr_storage*)':
src/address.cpp:137:9: warning: unused variable 'unused' [-Wunused-variable]
137 | int unused;
| ^~~~~~~
At global scope:
cc1plus: note: unrecognized command-line option '-Wno-tautological-constant-compare' may have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option '-Wno-atomic-alignment' may have been intended to silence earlier diagnostics
CXX src/libzmq_la-channel.lo
```
They will also seem to accept the -Wno-* variant when it's tested for
using AX_CHECK_COMPILE_FLAG. So, rather than test for -Wno-* variants
that the compiler may pretend to understand, test for the actual option,
and only enable the -Wno-* case when it is available.
This flag has been enabled for Darwin targets since the initial commit
in 4ed70a9302. However, aside from the
fact that we likely no longer want to suppress uninitialized warnings,
this flag wont suppress them anyways, as it's included in the
CXX flags before -Wall (which enables -Wuninitialized). i.e:
```bash
g++ -std=gnu++11 ... -Wno-uninitialized ... -Wall <rest of flags>
```
Solution: port the 2 new tests from oss-fuzz, and wire them up to
be ran manually with a static input in normal builds.
Add a specific configure option to use the external fuzzing engine
from oss-fuzz.
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.
Allow "configure --disable-maintainer-mode" to disable timestamp checking.
This is useful for one-off builds, in particular on e.g. clusters, where slightly skew clocks force aclocal and friends to kick in for no good reason.
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
Solution: go back to using -Wl,--version-script.
Use ax_check_vscript.m4 from the autoconf-archive to detect support on
multiple platforms (eg Solaris ld(1) -M).
libtool -export-symbols-regexp used ld(1) --retain-symbols-file under
the hood, the latter lets some C++ weak symbols make their way into the
dynamic symbols table, along with the zmq_* interface. The reason for
such behavior is unknown to me.
