Signed-off-by: Martin Sustrik <sustrik@250bpm.com>

Signed-off-by: Martin Sustrik <sustrik@250bpm.com>

The comment about memory ownership in uuid_t::to_string
was misleading as on most platforms the buffer is a field
of the object;
The string allocated in UuidToString() wasn't properly freed
with RpcStringFree()
Signed-off-by: Taras Shpot <taras.shpot@eleks.com>

Upgrade OpenPGM to version 2.1.28 for ZeroMQ 2.0.x. Now we also use the
DFSG-compliant upstream release tarball.
Signed-off-by: Martin Lucina <mato@kotelna.sk>

Add missing files needed for regenerating configure to the distribution;
add MAINTAINERS; improve maintainer-clean to produce a really clean tree.
Signed-off-by: Martin Lucina <mato@kotelna.sk>

* Added a version.sh and relevant changes to configure.in to extract the API
  version from zmq.h at the time autogen.sh is run.
* Moved the version macros to be next to zmq_version in zmq.h and improved
  the comments.
* Modified ZMQ_MAKE_VERSION to use (x) instead of plain x when expanding
  macro parameters.
Signed-off-by: Martin Lucina <mato@kotelna.sk>

Signed-off-by: Sebastian Otaegui <feniix@gmail.com>

For historic reasons (mainly compatbility with really old libtool), configure was
patching libtool to not use rpath in binaries. This breaks (among other things)
correct operation of "make check" since the test binaries may not be run with
the correct shared library version.

Current best practice as seen e.g. at http://wiki.debian.org/RpathIssue suggests
that this is no longer an issue, so I'm removing the code that patches libtool.
Signed-off-by: Martin Lucina <mato@kotelna.sk>

When adding ZMQ_VERSION macros, I incorrectly removed
the PACKAGE_VERSION macro. Adding it back.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>

Macro ZMQ_VERSION represents the current version of 0MQ
Macro ZMQ_MAKE_VERSION(major,minor,patch) allows to create
a representation of the specified version.
The versions can be compared using simple <, >, ==, etc.
operators.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>

if TSC jumps backwards (in case of migration to a different CPU core) latency peak may occur -- fixed

Thanks to Matt Weinstein for the suggestion.

Change 'make dist' to generate the Git ChangeLog file, that way it doesn't
have to be manually updated nor kept in Git which causes unnecessary work.

Also change 'make dist' to invoke 'dist-zip' automatically to generate a
ZIP as well as a .tar.gz.

Thanks to http://live.gnome.org/Git/ChangeLog for the inspiration to
automatically generate ChangeLog.

Ensure that 0MQ does not attempt to call select() on more than FD_SETSIZE
file descriptors.

This reverts commit f575f252.

Conflicts:

	doc/zmq_device.txt

This reverts commit 6cd90304.

This reverts commit 77a3c36f.

This reverts commit c51de31f.

This reverts commit 6ff19399.

This reverts commit 13f3481e.

Conflicts:

	doc/zmq_device.txt
	doc/zmq_tcp.txt

This reverts commit 96bcc9e6.

This reverts commit de017375.

This is because as it adds the 255th element at a node it attempts to calculate
the count member var which is an unsigned char via count = (255 -0) + 1; and
pass the result to realloc. Unfortunately the result is zero and realloc returns
null; the prefix_tree asserts. I have fixed it by making the count an unsigned
short.

I was hitting an issue with an SCL enabled STL library in connection with the
way select_t::loop was erasing retired fd's. The problem as identified by the
SCL assertion was that by the time the iterator given to the erase method was
called it was considered invalid by the library. I am not sure this isn't just
a "quirk" of the MSVC STL library as the other code looks valid to me as well.