libzmq: a C++98 messaging kernel whose platform table predates its own last commit

The repository is the socket layer, not the bindings most people install

libzmq is the ZeroMQ core engine, and the repository description is precise about what that means: it implements ZMTP/3.1, the wire protocol, in C++. The C++ header and binding layers that most developers actually name in a build file sit above this.

That distinction decides what you are reading when you land here. The README's welcome section describes the library as extending the standard socket interfaces with features traditionally provided by specialised messaging middleware products, and enumerates what the sockets give you: an abstraction of asynchronous message queues, multiple messaging patterns, message filtering for subscriptions, and access to multiple transport protocols.

What is not in that list is a broker. Nothing in this repository runs as a service you deploy to route messages between your own processes, which is the design choice that distinguishes ZeroMQ from a conventional message bus. The unit of deployment is the socket inside your program, and the pattern is decided by which socket type you bind and connect.

C++98 is the baseline, and the C++11 fragments are opt-in rather than assumed

The library is mainly written in C++98 with some optional C++11 fragments. That sentence in the supported-platforms section is the single most consequential line for an integrator, because it tells you what your toolchain has to accept before the project will build at all.

The optional part is visible in the primary CI table rather than hidden. The Ubuntu 14.04 entry built with clang 5.0.0 under autotools is marked STABLE with extras including GSSAPI, PGM, NORM, and the remark C++98 mode only. The neighbouring gcc 4.8.4 row under the same OS adds TIPC, IPV6, both POLLER=poll and POLLER=select, plus valgrind and address sanitizer executions.

Configuration goes through either autotools or CMake, and the repository carries both: configure.ac, Makefile.am, acinclude.m4, autogen.sh and an m4/ directory on one side, CMakeLists.txt on the other. The CI table shows both being exercised on the same platform, though the autotools rows list extras (GSSAPI, PGM, NORM, TIPC) that the CMake row does not.

Two files exist purely to keep this codebase consistent: .clang-format and .clang-tidy at the root.

The platform table names Visual Studio 2013 and Ubuntu 14.04, and admits it goes stale

Read the supported-platforms table as a record of what CI was configured to try, not as a statement about what libzmq runs on.

The primary CI entries are old in a specific way. Windows Server 2012 R2 appears against Visual Studio 2008, 2010 SP1, 2012 Update 5, 2013 Update 5 and 2015 Update 3, mostly marked DRAFT, with the 2013 row marked STABLE for x86 Release only and carrying POLLER=epoll. Above that sits Windows Server 2016 with Visual Studio 2017 15.9.6 and CMake 3.13.3. There is no entry for any Windows release later than Server 2016. On the Unix side the newest is Mac OS X 10.13 with Xcode 9.4.1, and the newest Linux is Ubuntu 14.04.5 LTS. Android NDK r25 covers arm, arm64, x86 and x86_64, marked DRAFT.

The project flags this itself. The note under the table says the platforms are regularly updated by the service providers, so the information might get out of date without any changes on the side of libzmq, and it points at the AppVeyor and Travis CI changelogs for those updates. The table ages because the CI vendors change under it.

The secondary CI list is less detailed: CentOS, Debian 8.0 and 9.0, Fedora 28 through Rawhide, RedHat Enterprise Linux 7, SuSE Linux Enterprise 12 SP4 and 15, and Ubuntu releases from 12.04 through 18.04. Architectures there reach further than the primary list, covering ARM32, ARM64, ppc64 and s390x, with the compiler column left as question marks.

The Dockerfile runs make check, so a failing test suite stops the image

The repository ships its own build recipe, and the recipe is a two-stage Debian build where the test suite sits in the middle of the install rather than after it.

The builder stage starts from debian:buster-slim and installs autoconf, automake, build-essential, git, libkrb5-dev, libsodium-dev, libtool and pkg-config. It then runs the autotools path with both security libraries enabled, and it runs the test suite before installing:

./autogen.sh \
    && ./configure --prefix=/usr/local --with-libsodium --with-libgssapi_krb5 \
    && make \
    && make check \
    && make install

Two details matter more than the package list. The configure line passes --with-libsodium and --with-libgssapi_krb5, so curve and GSSAPI are on by default in this image rather than left to whatever the base distribution provides. And `make check` runs before `make install`, so a build whose tests fail never produces an installed library.

The runtime stage is the same base with libsodium23 and libkrb5-dev installed and /usr/local copied across, then `ldconfig` followed by `ldconfig -p | grep libzmq`. That last grep is a smoke test: if the library did not land where the dynamic linker looks, the build step fails instead of producing an image that cannot load libzmq at runtime.

Two things are worth noting about the base. buster-slim is an old Debian release, and the runtime stage installs libkrb5-dev, a development package, where the runtime library would do.

Three CI systems are wired at once, plus Doxygen, Read the Docs and a QNX build tree

The top-level tree shows how much of the surrounding toolchain lives in this repository rather than in documentation or an external service.

Configuration for at least three CI systems sits in the repository. The README badges point at a GitHub Actions workflow and at AppVeyor, and the root carries a .travis.yml and an appveyor.yml alongside a Jenkinsfile and two shell entry points named ci_build.sh and ci_deploy.sh. Several systems means several failure notifications to triage, and it means a platform can be green on one and absent from another without anyone noticing.

Documentation is built from the tree as well. Doxygen.cfg sits at the root alongside a doc/ directory, README.doxygen.md sits beside it, and .readthedocs.yaml points at a Read the Docs build. A README.cygwin.md covers the Cygwin case specifically, and SupportedPlatforms.md sits at the root too.

Beyond the mainstream paths there are dedicated ones. build_qnx/ is a separate build tree for QNX, packaging/ holds packaging inputs, and .obs/ is present for distribution builds. perf/ holds performance work and tools/ holds command-line utilities, so the repository contains more than the library: it contains the tools used to measure and drive it.

Versioning is scripted. version.sh and config.sh sit at the root, and .git-blame-ignore-revs is present, which exists to keep bulk commits out of git blame output.

The newest tag is v4.3.5 from 2023, and the branch took commits in July 2026

The gap between releases and commits is the fact to plan around.

The three most recent tags are v4.3.5 published on 2023-10-09, v4.3.4 on 2021-01-17 and v4.3.3 on 2020-09-07. Between v4.3.4 and v4.3.5 there is a gap of more than two years, and before that a gap of four months. This is not a project with a steady release train.

The repository is not archived, and its last push was on 2026-10-18, about three years after the newest tag. Commits are landing; tags are not following them.

For a library that other people's builds link against, that difference matters concretely. A team that pins v4.3.5 gets a versioned artefact they can name in a licence review and in a vulnerability scan. A team that builds from master gets the fixes but has to describe the version by commit hash, and has no dated release to point an auditor at. The branch is not stale, but it is untagged, and those are different problems.

The repository root also carries NEWS, AUTHORS, INSTALL and SECURITY.md, which is the file layout a project settles into once it has a process rather than just a build.

Where libzmq leaves the work to you, and what the README does not cover

Two gaps are worth naming before anyone adopts this.

The first is installation. The install material visible in the repository is the supported-platform table and a Dockerfile. If you are on Linux your distribution likely ships a development package for the library, and if you are not, the path is the autotools sequence shown above, run as ./autogen.sh then ./configure then make.

The second is what sits above the socket. The welcome section mentions multiple messaging patterns in a single phrase.

What the repository does give you is test and measurement infrastructure: a tests/ directory, a separate unittests/ tree, perf/ for benchmarks and tools/ for command-line programs. A team that wants to know how the library behaves on its own workload has the harness to find out.

The right summary is that libzmq is infrastructure you link against, with a mature codebase and an active branch, whose release artefacts stopped being refreshed in 2023.

Editorial conclusion

libzmq fits a team binding a C or C++ service to ZeroMQ socket semantics directly, on Linux or macOS, who can run the project's own test suite during their build. It does not fit a team that needs a released version they can audit against a dated tag, because the newest tag is v4.3.5 from 2023-10-09 while the branch took commits as recently as 2026-10-18, and it does not fit a Windows team that trusts the platform table, since its newest entry is Windows Server 2016 with Visual Studio 2017. Before adopting it, build from source with ./configure --prefix=/usr/local --with-libsodium --with-libgssapi_krb5 and let make check run, then pin to a commit rather than to the tag.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. zeromq/libzmq on GitHub