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 4ed70a930202b103e7e80b8dc925e0aaa4622595. 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.
Solution: if the compiler supports it, pass C++98-compat flags.
Currently Clang supports this flag but GCC does not.
Add a new flag to enable it, as building with C++98-compat but also
with -std=gnu++11 will cause a lot of warnings due to the backward
compat ifdefs.
Add a CI job to run it and ensure we don't break compatibility.
Solution: ignore tautological-constant-compare warnings, as they
might be useless on 64 bit but they are not on 32 bit where sizeof
size_t != sizeof uint64_t
