bump czmq/libzmq, statically link against them

[bwalex]

Statically link against libzmq, czmq and libsodium, to avoid issues with
dynamic linking of libzmq (see e.g. #43).

Whilst on it (mainly because the existing versions of czmq/libzmq were
being a PITA to get to link statically properly), also bump the versions
of libzmq and czmq.

With czmq now being at API v3, also adjust the extension to be
compatible with it. It still uses a fair number of deprecated APIs, but
it absolutely works with API v3.

Fixes #43
Fixes #45 (hopefully)
Fixes #47

[bwalex]

I'm a bit puzzled as to why TestZmqBeacon#test_announce_lookup fails on Travis; I can't reproduce that locally at all - for me it just works, and provides the expected address, etc.

[bwalex]

I should've probably read the error message on Travis properly - it simply can't find a broadcast interface.

[methodmissing]

Nice work :-) reviewing shortly

[methodmissing]

Tried to repo locally, but having some build issues on OS X:

/bin/sh ../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I.   -Wall -Wno-uninitialized -D_DARWIN_C_SOURCE -D_REENTRANT -D_THREAD_SAFE  -DZMQ_FORCE_KQUEUE -fvisibility=hidden  -g -O2 -MT libzmq_la-ctx.lo -MD -MP -MF .deps/libzmq_la-ctx.Tpo -c -o libzmq_la-ctx.lo `test -f 'ctx.cpp' || echo './'`ctx.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -Wall -Wno-uninitialized -D_DARWIN_C_SOURCE -D_REENTRANT -D_THREAD_SAFE -DZMQ_FORCE_KQUEUE -fvisibility=hidden -g -O2 -MT libzmq_la-ctx.lo -MD -MP -MF .deps/libzmq_la-ctx.Tpo -c ctx.cpp  -fno-common -DPIC -o .libs/libzmq_la-ctx.o
ctx.cpp:39:10: fatal error: 'sodium.h' file not found
#include <sodium.h>
         ^
1 error generated.
make[2]: *** [libzmq_la-ctx.lo] Error 1

What's your local environment atm.? Also regarding Travis, looks like it references this Issue travis-ci/travis-ci#2966 which was reported by zyre which also depends on czmq.

I'm OK with relaxing the test case and releasing the v3 API with a sustainable async workaround. Thoughts?

[bwalex]

On 26/10/2015 00:31, Lourens Naudé wrote:

Tried to repo locally, but having some build issues on OS X:

|/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-Wall -Wno-uninitialized -D_DARWIN_C_SOURCE -D_REENTRANT
-D_THREAD_SAFE -DZMQ_FORCE_KQUEUE -fvisibility=hidden -g -O2 -MT
libzmq_la-ctx.lo -MD -MP -MF .deps/libzmq_la-ctx.Tpo -c -o
libzmq_la-ctx.lo test -f 'ctx.cpp' || echo './'ctx.cpp libtool:
compile: g++ -DHAVE_CONFIG_H -I. -Wall -Wno-uninitialized
-D_DARWIN_C_SOURCE -D_REENTRANT -D_THREAD_SAFE -DZMQ_FORCE_KQUEUE
-fvisibility=hidden -g -O2 -MT libzmq_la-ctx.lo -MD -MP -MF
.deps/libzmq_la-ctx.Tpo -c ctx.cpp -fno-common -DPIC -o
.libs/libzmq_la-ctx.o ctx.cpp:39:10: fatal error: 'sodium.h' file not
found #include <sodium.h> ^ 1 error generated. make[2]: ***
[libzmq_la-ctx.lo] Error 1|
I'll get it working on my Mac - shouldn't be much of an issue. I've been
running it on several linux machines (Ubuntu and Archlinux).

||

What's your local environment atm.? Also regarding Travis, looks like
it references this Issue travis-ci/travis-ci#2966
travis-ci/travis-ci#2966 which was
reported by zyre which also depends on czmq.

That makes sense, then.

I'm OK with relaxing the test case and releasing the v3 API with a
sustainable async workaround. Thoughts?

I'm not sure what you mean by that. This doesn't yet make use of most of
the new things in the v3 API, it's just getting it to work with it. The
ruby API is virtually unchanged (except for the minor changes you can
see in the tests).

However, with this bit of groundwork done, it should be a lot easier to
make use some of the nice new v3 features such as zsock to improve the
Ruby side of things - that would imply breaking API changes, however.

[bwalex]

Interesting. I just ran 'rake compile test' on my OS X (Yosemite) and it compiled just fine, and passed all the tests. Any ideas?

[methodmissing]

Likely El Capitan specific. Will investigate further.

On Monday, 26 October 2015, Alex Hornung [email protected] wrote:

Interesting. I just ran 'rake compile test' on my OS X (Yosemite) and it
compiled just fine, and passed all the tests. Any ideas?

—
Reply to this email directly or view it on GitHub
#51 (comment).

[bwalex]

any news on what might be the issue you are seeing?

[paddor]

@bwalex If you're just looking for CZMQ API v3 support, you might wanna take a look at CZTop, a new CZMQ binding based on FFI. It supports ZMQ >= 4.0 and CZMQ >= 3.0.2.

[bwalex]

@paddor The main thing I'm interested in is actually to be able to statically link with just about all of the individual libraries (i.e. libzmq, czmq and libsodium).

[paddor]

@brianmario Okay, never mind. :-)