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.
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
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.
Solution: remove objects optimisation in library build (similar to #2860)
and set PUBLIC compile definitions on all static builds instead of MSVC
only.
Solution: change case of `WinSock2.h Iphlpapi.h Rpc.h` to match the
files on disk. This is only noticeable when cross-compiling from a
case-sensitive system so wouldn't get picked up in MSVC or mingw
builds running on a windows machine.
MSDN uses capitalised versions in prose and lowercase in code examples:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms737629(v=vs.85).aspxFixes#2978, the missing library message is a little misleading.
This fixes an error with the cmake install configuration, which
attempted an invalid copy of a .pdb file on windows, when the
BUILD_SHARED option is disabled.
