Solution: check if a session's _pipe has been allocated before using
it, since as a consequence of creating the pipes after the handshake
it's no longer guaranteed to be there.
(cherry picked from commit 350b4b34f460b91b8fa8f692cf6bc30d561a5711)
Conflicts:
src/session_base.cpp
The deployment is triggered by tagging on the zeromq/libzmq repository.
Of the many builds travis is checking only the default one with
libsodium and drafts disabled is used for deployment.
For now the results of `make distcheck` are deployed as well as their
md5 and sha1 hash sums. Further changes may upload a generated
Changelog as well.
Solution: add the document files to the MAN_DOC and MAN_HTML targets
in doc/Makefile.am only if BUILD_DOC and INSTALL_MAN are set,
otherwise leave the targets empty to avoid errors in make distcheck.
Solution: add -lssp on Solaris only when libsodium is enabled and has
been found. Also disable pedantic and Werror, as libsodium headers
use pragma diagnostic which are not available in gcc 3.4.
Solution: in the Windows-specific ifdef in tcp_listener set_address,
check for error and set errno only after the IPv4 fallback has failed
too, to avoid setting errno when the socket creation succeeds through
the fallback.
Solution: if opening an IPv6 TCP socket fails because IPv6 is not
available, try to open an IPv4 socket instead when creating and
connecting a TCP endpoint.
Solution: if opening an IPv6 TCP socket fails because IPv6 is not
available, try to open an IPv4 socket instead when creating and
binding a TCP endpoint.
While sending very large messages (far beyond what fits in a the tcp
buffer, so it takes multiple sendto system calls for it to finish),
zmq_close will close the connection regardless of ZMQ_LINGER.
In case no engine is attached, a pipe->check_read() is needed to look
for the delimiter in the pipe and ultimately trigger the pipe
termination.
However, if there *is* an engine attached, the check_read() looks ahead
and finds the delimiter and terminates the connection even though the
engine might actually still be in the middle of sending a message.
This happens because while the io_thread is still busy sending the data,
the pipe can get terminated and the io thread ends up being terminated.
Solution: always initialised zmq::options_t class variables arrays to
avoid reading uninitialised data when CURVE is not yet configured and
a getsockopt ZMQ_CURVE_{SERVER | PUBLIC | SECRET]KEY is issued.
Backport from libzmq.
Backported from zeromq/libzmq@032c5ed
This commit fixes the following warnings:
8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
CMake Warning (dev) at builds/cmake/Modules/FindAsciiDoc.cmake:9 (find_program):
Policy CMP0053 is not set: Simplify variable reference and escape sequence
evaluation. Run "cmake --help-policy CMP0053" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.
For input:
'$ENV{PROGRAMFILES(X86)}/asciidoc'
the old evaluation rules produce:
'/asciidoc'
but the new evaluation rules produce an error:
Syntax error in cmake code at
/path/to/builds/cmake/Modules/FindAsciiDoc.cmake:13
when parsing string
$ENV{PROGRAMFILES(X86)}/asciidoc
Invalid character ('(') in a variable name: 'PROGRAMFILES'
Using the old result for compatibility since the policy is not set.
Call Stack (most recent call first):
CMakeLists.txt:193 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
and
8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
CMake Warning (dev) at builds/cmake/Modules/FindAsciiDoc.cmake:15 (find_program):
Policy CMP0053 is not set: Simplify variable reference and escape sequence
evaluation. Run "cmake --help-policy CMP0053" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.
For input:
'$ENV{PROGRAMFILES(X86)}/asciidoc'
the old evaluation rules produce:
'/asciidoc'
but the new evaluation rules produce an error:
Syntax error in cmake code at
/path/to/builds/cmake/Modules/FindAsciiDoc.cmake:19
when parsing string
$ENV{PROGRAMFILES(X86)}/asciidoc
Invalid character ('(') in a variable name: 'PROGRAMFILES'
Using the old result for compatibility since the policy is not set.
Call Stack (most recent call first):
CMakeLists.txt:193 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
The header symbols are declared extern "C",
however the the implementations are compiled in a C++ source.
The result is that the library symbols get C++ name mangled
and the resulting dll is missing all of the symbols from the header.
The fix was to add extern "C" in zmq.cpp and zmq_utils.cpp
The static library was given the same OUTPUT_NAME as the dynamic library.
This leads to one library's build products overwriting the other.
The fix sets the name "libzmq-static" for the static library.
Autogen.sh looks for the libtool command as a mean to check if
libtool is available. But distributions like Debian and Ubuntu have
split the libtool package, and the libtool script is now in a
separate package. The solution is to look for the libtoolize command
too before failing, which is what the Autotools chain actually needs
on Linux. Keep checking for libtool to be compatible with OSX, where
the opposite is true.
backport of zeromq/libzmq#721
In the discussion, it was decided to backport, but that never actually happened.
test file was renamed after the above PR, so the version from master is pulled in here.
indentation was correct, but poll was inside `if control`,
causing it to only be called if there is a control message.
This would cause proxy messages to only be delivered after a control message had been sent.
