5.7. Optional support libraries

Beyond the required support libraries, PMIx will use a number of further libraries if it finds them at configure time, and will build without them otherwise.

None of these is needed to produce a working PMIx. Each one either enables a capability that some sites want and others do not, or makes something PMIx already does faster — and the distinction matters: a missing library from the first group means a feature is simply absent, while a missing library from the second group means PMIx still works but does more of the work itself.

Important

The selection happens at configure time, not run time. A component is compiled only if its library was found, so an absent library is not something PMIx can report later or fall back from at run time — the code was never built. If you care whether a particular one was picked up, check the configure output summary rather than assuming.

5.7.1. Recommended

These do not add features, but installing at least one of them is worthwhile on any system that runs jobs at scale.

Library	configure option	What it does
Zstandard	--with-zstd	Builds the pcompress/zstd component. Preferred where available: it is both faster and produces smaller output than the zlib components on the data PMIx actually compresses.
zlib-ng	--with-zlibng	Builds the pcompress/zlibng component — a faster implementation of the same DEFLATE format zlib produces.
LZ4	--with-lz4	Builds the pcompress/lz4 component. The fastest of the four and the least dense, so it is not preferred over zstd by default; it is the one to select where daemon CPU matters more than bytes on the wire.
zlib	--with-zlib	Builds the pcompress/zlib component. Almost universally available, which is why it is the usual fallback.

What compression is for. PMIx compresses large data objects before they are shipped over the wire or stored — a job map, a modex blob, a set of network endpoints. At scale those are the objects whose size dominates job start-up, so a system with no compression library at all will see longer start-up times and larger memory footprints. PMIx says so once, at start-up, on servers and tools (clients stay silent); the warning can be silenced with pcompress_base_silence_warning=1 if the trade is deliberate.

You do not need more than one. Exactly one component is active, chosen by priority: zstd (90), then zlibng (75), then lz4 (60), then zlib (50). Building several is harmless — the highest-priority one wins and the others are simply never selected, and any of them can be forced at run time with --pmixmca pcompress <name>.

Important

You need the development package, not just the runtime library. A pcompress component is compiled only if configure finds the library’s headers — zstd.h, lz4frame.h, zlib.h. A system carrying libzstd.so but not libzstd-dev builds no zstd component at all, and silently falls back to whichever lower-priority library does have headers installed. The distribution packages are typically libzstd-dev, liblz4-dev and zlib1g-dev (Debian/Ubuntu), or libzstd-devel, lz4-devel and zlib-devel (RHEL/SUSE). Check the External Packages lines of the configure summary to see what was actually found.

Warning

All processes in a job must use the same component. zlib and zlib-ng both emit standard DEFLATE and are freely interchangeable, so a build that picks one on one node and the other elsewhere is fine. A zstd or lz4 blob is not DEFLATE, and compressed data does cross nodes, so mixing either of those with each other or with a zlib-based installation within one job will not interoperate. Both refuse a blob that does not carry their own frame magic, so the mismatch surfaces as a clean error rather than as corrupted data — but it does not work. In practice this follows from a shared installation; it is worth knowing during a rolling upgrade.

5.7.2. Optional features

Each of these enables something PMIx cannot do otherwise. Their absence costs you that capability and nothing else.

Library	configure option	What it enables
MUNGE	--with-munge	Builds the psec/munge component, which authenticates PMIx connections using MUNGE credentials. Without it, the other psec components (native, none) remain available.
libesmtp	--with-smtp	Builds the plog/smtp component, which can emit log messages by email. Without it, the other plog components are unaffected.
libltdl	--with-libltdl	Builds the pdl/plibltdl component, an alternative to pdl/pdlopen for loading DSO components. pdlopen (priority 80) is preferred over plibltdl (50) where both are built.

Note

``dlopen`` is worth a word of its own. It is not a package you install — it is part of the C library on essentially every supported platform — but it is what pdl/pdlopen needs, and pdl is what loads MCA components built as DSOs. A build with neither pdlopen nor plibltdl can still work, but only if every component is compiled statically into the library.

5.7.3. Specifying where to find them

Every option above follows the same conventions as the required libraries: --with-FOO=DIR names an installation prefix and --with-FOO-libdir=LIBDIR names the library directory when it is not DIR/lib. They are listed in full under CLI options for optional support libraries.

One behavior is worth stating explicitly, because it differs from a plain search:

Important

Naming a library makes it mandatory. If you pass --with-zstd (with or without a path) and configure cannot find a usable Zstandard, it will abort rather than quietly build without it. That is deliberate — asking for something and silently not getting it is the failure mode these options exist to prevent. Omit the option entirely to get a best-effort search.

For example, to build against compression and MUNGE installations under /opt:

./configure --prefix=$HOME/pmix-install \
    --with-zstd=/opt/zstd \
    --with-munge=/opt/munge ...