On some cases, -latomic is needed for likning, and since the current
acinclude.m4 checks only compilation we can sometimes miss the need for -latomic
and the linking process will fail.
Therefore, the AC_CHECK_IFELSE was replaced with AC_LINK_IFELSE. If the first
try fails, we try to link again with -latomic and add LIBS="-latmoic" in case we
succeeded.
Signed-off-by: Asaf Kahlon <asafka7@gmail.com>
Solution: replace it with the ip_resolver code shared with the TCP
address code
It simplifies the UDP parsing code and makes it behave more like the
TCP counterpart, in particular it's not possible to connect to hosts
by name and bind by NIC names.
It also adds support for "*" port resolving to 0 (useful to let the OS
allocate the port number).
Solution: return an error in this situation but still allow using an explicit
"0" if somebody really wants to connect to port 0.
This shouldn't break any existing code because a "*" port was already rejected
in an early test in the TCP path in zmq::socket_base_t::connect.
Solution: ignore command messages in the REQ session to avoid
disrupting the state machine.
Commands are handled by the engine before handing off to the session.
Problem: When building libzmq with CMake, the installed libzmq.dylib
has a relative install name (otool -D libzmq.dylib) on MacOS. This
is a regression against building via autotools which sets an
absolute install name. Effectively, the CMake built libzmq.dylib
is rendered useless if installed in non-system directories and
used in environments without explicit DYLD_LIBRARY_PATH mgmt. For
example running any of the installed executables currently fails:
$ /some_install_prefix/bin/inproc_lat
dyld: Library not loaded: libzmq.5.dylib
Referenced from: /some_install_prefix/bin/inproc_lat
Reason: image not found
Trace/BPT trap: 5
Solution: Best practice is to install relocatable dylibs.
On MacOS this means setting an install name with a special prefix,
e.g. @rpath/libzmq.dylib, and adding the relevant search paths
to the embedded rpath list. In this patch the necessary CMake options
are added to generate the desired relocatable dylibs. Find more
information on: https://cmake.org/Wiki/CMake_RPATH_handling.
event_accepted() already accepts fd_t type and there is no reason to cast it to int type
Moreover, on Windows x64 this leads to truncation memsize -> int
The original configure.ac tries to check for dladdr, but it actually needs
it only in case we have libunwind (which has a another section and checks for it
too).
This can fail the build on systems without dynamic linking support.
Therefore, the dladdr check has to be preformed only when checking libunwind.
Signed-off-by: Asaf Kahlon <asafka7@gmail.com>
