Skip to content

Problem: cmake-built libzmq is not binary-compatible with autotools builds #2887

@minrk

Description

@minrk

tl;dr: if a library links zeromq built normally and the same version of ibzmq is rebuilt with cmake, everything that had linked to libzmq will be broken until they are rebuilt.

Versioning libraries is fraught and complicated on different platforms. #2886 fixes SONAME of cmake files, but does not fix the library versioning. After #2886, filenames are now mostly correct (on linux, not quite on mac). This does not, however, fix the versions of the library itself. See this output for cmake and autotools builds of e2ed5a3:

minrk[11:39]~/dev/zmq/libzmq (master) $ otool -L /tmp/normal/lib/libzmq.dylib
/tmp/normal/lib/libzmq.dylib:
	/tmp/normal/lib/libzmq.5.dylib (compatibility version 7.0.0, current version 7.4.0)
minrk[11:48]~/dev/zmq/libzmq (master) $ otool -L /tmp/cmake/lib/libzmq.dylib
/tmp/cmake/lib/libzmq.dylib:
	libzmq.5.dylib (compatibility version 5.0.0, current version 5.1.4)

Now, what CMake does isn't necessarily wrong here. Ultimately, all that matters is that builds are internally consistent. The problem comes from having two build systems, and those build systems having incompatible idiosyncrasies.

In order for cmake and autotools builds to be compatible, The compatibility version and current version for cmake must be exactly identical for both builds. The reasons for libtool's version choices are a bit weird and historical, but they are necessary for cmake-built libzmq to be compatible with normal libzmq.

Right now, we have LTVER=6.4.1. That means:

  • current is 6
  • implementation is 4
  • age is 1
  • ABI version is current - age (6-1=5)
  • soversion is ABI (5)
  • compatibility version is current + 1 (6+1=7)
  • current version is compatibility.revision.0 (7.4.0)

CMake has to match all of libtool's platform-specific weirdness if it wants to be compatible with normal builds of libzmq. I'm not sure how to do that.

I think having two build systems that are incompatible is a source of major problems. My recommendation would be to deprecate one or the other, or at least place big caveats that anything that adopts one must never switch without ensuring that all downstream packages are rebuilt. Personally, I would recommend that CMake builds of zeromq be reserved for Windows.

cc @SylvainCorlay

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions