Solution: revert the objects optimisation, and go back to building
everything twice on Windows, as the static builds needs different
preprocessor definitions from the shared one, so the objects have to be
rebuilt.
Keep the optimisation for all the other platforms.
Fixes#2858
* Background thread scheduling
- add ZMQ_THREAD_AFFINITY ctx option; set all thread scheduling options
from the context of the secondary thread instead of using the main
process thread context!
- change ZMQ_THREAD_PRIORITY to support setting NICE of the background
thread when using SCHED_OTHER
Linux now supports Virtual Routing and Forwarding (VRF) as per:
https://www.kernel.org/doc/Documentation/networking/vrf.txt
In order for an application to bind or connect to a socket with an
address in a VRF, they need to first bind the socket to the VRF device:
setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);
Note "dev" is the VRF device, eg. VRF "blue", rather than an interface
enslaved to the VRF.
Add a new socket option, ZMQ_BINDTODEVICE, to bind a socket to a device.
In general, if a socket is bound to a device, eg. an interface, only
packets received from that particular device are processed by the socket.
If device is a VRF device, then subsequent binds/connects to that socket
use addresses in the VRF routing table.
Solution: we can use 'CMAKE_SYSTEM_VERSION' instead of
'${CMAKE_SYSTEM_VERSION}' for the 'if' clauses.
CMake fails to evaluate condition when CMAKE_SYSTEM_VERSION is
empty, which can happen with a default installation of Mingw-w64
in Linux.
Some #define switches cause the body of entire files to be omitted. This
causes a linker warning on Visual Studio 2017, for example
warning LNK4221: This object file does not define any previously
undefined public symbols, so it will not be used by any link
operation that consumes this library
Since this is warning us about something that shouldn't be
earth-shattering news, we add a linker flag to suppress this warning on
MSVC builds.
Add two new options to CMakeLists.txt:
`BUILD_SHARED` - Whether or not to build the shared object (Default: ON)
`BUILD_STATIC` - Whether or not to build the static archive (Default: ON)
Remove the `build/msvc` include path from the test project to fix a
problem with the order of the include paths. Additionally remove the
unnecessary `include_directories` from the master project.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
* add define for windows/UWP
* prevent issue with COM references
* gettickcount not available on uwp
* add compiler definitions
* add convenitnece cmake file
* brute force uwp compilation
* fix compiler version
* cosmetics
Solution: use pthread API to set the name. For now call every thread
"ZMQ b/g thread". Would be nice to number the I/O threads and name
explicitly the reaper thread, but in reality a bit of internal API
churn would be necessary, so perhaps it's not worth it.
This is useful when debugging a process with many threads.
Solution: set SOVERSION in CMakeLists to match the SONAME generated
by libtool so that there is no mismatch between the output of the
*NIX build systems.
Before:
$ ls -l
total 2696
lrwxrwxrwx 1 luca luca 15 Dec 1 22:36 libzmq.so -> libzmq.so.4.2.0
lrwxrwxrwx 1 luca luca 15 Dec 1 22:36 libzmq.so.4.2.0 -> libzmq.so.4.2.1
-rwxr-xr-x 1 luca luca 906168 Dec 1 22:36 libzmq.so.4.2.1
$ readelf -d libzmq.so.4.2.1 | grep SONAME
0x000000000000000e (SONAME) Library soname: [libzmq.so.4.2.0]
After:
$ ls -l
total 2700
lrwxrwxrwx 1 luca luca 15 Dec 1 22:31 libzmq.so -> libzmq.so.5.1.0
-rwxr-xr-x 1 luca luca 906168 Dec 1 22:31 libzmq.so.4.2.1
lrwxrwxrwx 1 luca luca 15 Dec 1 22:31 libzmq.so.5.1.0 -> libzmq.so.4.2.1
$ readelf -d libzmq.so.4.2.1 | grep SONAME
0x000000000000000e (SONAME) Library soname: [libzmq.so.5.1.0]
Solution: use only Libs.private to avoid breaking application builds.
Even though Requires.private are supposed to be parsed only if
pkg-config is called with --static, the --cflags parameter is enough
to trigger the parsing, causing build failures for applications that
do not (and should not) depend on libzmq's dependencies.
Solution: add dependencies, if necessary, to the .private Libs and
Requires field of the pkgconfig file at build time.
This way pkg-config --static --libs libzmq will correctly print
dependencies if they were used to build the static libzmq.a library.
Solution:
Add CMake option called WITH_MILITANT so that it aligns with the Autotools
build infrastructure; enabling this option defines ZMQ_ACT_MILITANT, which
enables assertions should malformed requests make their way into
zmq_setsockopt(3) or zmq_getsockopt(3).
Solution: add macro in ZMQSourceRunChecks.cmake and optionally
include the TIPC sources if the support is available.
More importantly, only run the TIPC tests if the support is there.
Solution: Add precompiled flags to CMakeList.txt for faster compiles
+ bonus - removed compilation warning on Windows by adding
add_definitions (-D_WINSOCK_DEPRECATED_NO_WARNINGS)
Solution: it's a lot of work to define the tests in project.gyp
so I did this using gsl to generate the JSON, from a small XML
list of the test cases.
To keep this, and the hundreds of .mk files, away from the root
directory, I've moved the gyp files into builds/gyp, where you
would run them.
It all seems to work now. Next up, OS/X and Windows :)
- they have no copyright / license statement
- they are in some randomish directory structure
- they are a mix of postable and non-portable files
- they do not conform to conditional compile environment
Overall, it makes it rather more work than needed, in build scripts.
Solution: clean up tweetnacl sauce.
- merged code into single tweetnacl.c and .h
- standard copyright header, DJB to AUTHORS
- moved into src/ along with all other source files
- all system and conditional compilation hidden in these files
- thus, they can be compiled and packaged in all cases
- ZMQ_USE_TWEETNACL is set when we're using built-in tweetnacl
- HAVE_LIBSODIUM is set when we're using external libsodium
This happens if you first configure with autotools, and then run
cmake. The problem is that the compiler finds the old src/platform.hpp
before looking for the one generated by CMake. Further, there are a
set of macros that configure passes via the command line, yet CMake
passes via platform.hpp. (HAVE_xxx for pollers, at least.) This means
you can't do a CMake build using the autotools platform.hpp.
Solution: remove any src/platform.hpp when running cmake. This is a
workaround. I'll fix the inconsistent macros separately.
It's unclear which we need and in the source code, conditional code
treats tweetnacl as a subclass of libsodium, which is inaccurate.
Solution: redesign the configure/cmake API for this:
* tweetnacl is present by default and cannot be enabled
* libsodium can be enabled using --with-libsodium, which replaces
the built-in tweetnacl
* CURVE encryption can be disabled entirely using --enable-curve=no
The macros we define in platform.hpp are:
ZMQ_HAVE_CURVE 1 // When CURVE is enabled
HAVE_LIBSODIUM 1 // When we are using libsodium
HAVE_TWEETNACL 1 // When we're using tweetnacl (default)
As of this patch, the default build of libzmq always has CURVE
security, and always uses tweetnacl.
Solution: bump CMake required version to 2.8.12 to avoid:
CMake Error at tests/CMakeLists.txt:110 (target_include_directories):
Unknown CMake command "target_include_directories".
VMCI transport allows fast communication between the Host
and a virtual machine, between virtual machines on the same host,
and within a virtual machine (like IPC).
It requires VMware to be installed on the host and Guest Additions
to be installed on a guest.
This is due to the mangled include of platform.h, which was to make
CMake happy.
Solution: in CMakeLists.txt, define USING_CMAKE and then look for
platform.h in current directory if that is defined, else look in
../src/ as one would expect.
A memcpy is eliminated when receiving data on a ZMQ_STREAM socket. Instead
of receiving into a static buffer and then copying the data into the
buffer malloced in msg_t::init_size, the raw_decoder allocates the memory
for together with the reference-counter and creates a msg_t object
on top of that memory. This saves the memcpy operation.
For small messages, data is still copied and the receive buffer is reused.
Solution: increased to 4096 by default for all MSVC builds, for MinGW,
and for CMake.
Note: this is a speculative change, it needs confirmation before we
can keep it. Particularly, there is some doubt that changing this in
libzmq will affect upstream applications using libzmq.dll.
fork() support is optional and its availability is correctly detected at
contfigure time.
But test_fork was all always built, preventing build for targets that do
not provide fork() from building successfully.
This pacth fixes the CMakeLists.txt on this point.
The decision about the poller mechanism to use (select, poll, ...)
was done twice: once by the build system and once by the code in
poller.hpp. As the build-system can actually detect the mechanisms
available, prefer that result to the hard coded defaults in
poller.hpp.
At the same time, remove the duplicate detection of select() vs.
poll()-variant from proxy.cpp, signaler.cpp and zmq.cpp.
This patch has not been tested on many build platforms: especially
the cmake build needs testing / patching. For the other builds,
hard code the result as these these are all Windows platforms.
The ${libdir} was getting replaced/removed by configure_file() making pkg-config give bad flags: -L -lzmq
My fix was to add @ONLY to configure_file() so ${} style pkg-config substitutions are left alone.
In addition, I put the other typical ${} substitutions back into the libzmq.pc, since its now safe.
