Problem: zsock options could be available at build time but not at runtime

[bluca]

I'm working on a solution, here's a brain dump while I think about it.

Distributions have automated dependency generation based on public symbols usage.

So if libfoo has foo () in version 2, and libbar uses it, the libbar package will automatically get a dependency on libfoo >= 2.

But for preprocessor definitions it's more tricky. These are included from headers at build time, so the build system when parsing the shared object has no way to know where they came from. The automatically generated symbols list cover public symbols in shared objects, not defines in headers.

More concretely, I have the case of CZMQ that is built against libzmq 4.2.0, and thus enables the various new socket options. But it doesn't use any of the new public symbols, so the dependency is on libzmq >= 4.1.2:

https://packages.debian.org/stretch/libczmq4

If at runtime I were to try to use, for example, zsock_set_use_fd, and it was done with libzmq 4.1.5, which is legal as far as dependencies are concerned, I would get an assert.

A solution could be to check in the option implementation at runtime, something like:

void
zsock_set_heartbeat_ivl (void *self, int heartbeat_ivl)
{
    assert (self);
#   if defined (ZMQ_HEARTBEAT_IVL)
    int major, minor, patch;
    zmq_version (&major, &minor, &patch);
    if (ZMQ_MAKE_VERSION (major, minor, patch) < ZMQ_MAKE_VERSION (4, 0, 0))
        return;
    int rc = zmq_setsockopt (zsock_resolve (self), ZMQ_HEARTBEAT_IVL, &heartbeat_ivl, sizeof (int));
    assert (rc == 0 || zmq_errno () == ETERM);
#   endif
}

We do have the means to do it, but we don't track them too well, so they'd have to be fixed first in the XML to be more precise with the version that introduced them.