Published Linux builds fail to start without libnatpmp, and have since v0.13.5 #45

New issue

Open

opened 2026-09-19 02:47:23 +00:00 by btcbob · 0 comments

btcbob commented

2026-09-19 02:47:23 +00:00

Owner

The published .tar.gz Linux builds are dynamically linked and fail in the loader on a machine
that does not already have the right libraries:

error while loading shared libraries: libnatpmp.so.1

The daemon never gets to print anything of its own, so it reads like a corrupt download.

How it was found

Smoke-testing the v0.13.8 daemon on three hosts before installing it. All three failed the same way;
only the machine that built it had the library. The full set the binary expects:

libnatpmp1  libminiupnpc17  libssl3
libboost-chrono1.74.0  libboost-filesystem1.74.0
libboost-program-options1.74.0  libboost-thread1.74.0

In practice everything except libnatpmp1 is usually present already.

This is three releases old

v0.13.7 links libnatpmp too. v0.13.3 does not, because NAT-PMP arrived in v0.13.5. So
every published Linux build since v0.13.5 has had this, and it went unnoticed because the nodes we
run were older than the feature that introduced it.

Documented, not fixed

dobbscoin.info/downloads and the v0.13.8 release page now list the packages. That is a workaround.
Options for an actual fix, none of them chosen here:

Link libnatpmp and libminiupnpc statically. Smallest change, removes the two libraries
almost nobody has. Boost and OpenSSL stay dynamic.
Link everything static, as the depends/ system already does for the Windows build. Biggest
binary, fewest surprises.
Build with --without-natpmp and drop the feature from the Linux builds. Cheapest, and loses
something that was advertised in v0.13.5.

The AppImage is unaffected: it bundles 64 libraries including libnatpmp.so.1, verified by
extracting it.

Worth noting for its own sake

A dependency that only the build host satisfies is invisible to the people who ship it. Smoke-testing
a release binary on a machine that did not build it is the cheap check that catches this class, and it
is not currently part of cutting a release.

The published `.tar.gz` Linux builds are dynamically linked and fail in the loader on a machine that does not already have the right libraries: ``` error while loading shared libraries: libnatpmp.so.1 ``` The daemon never gets to print anything of its own, so it reads like a corrupt download. ### How it was found Smoke-testing the v0.13.8 daemon on three hosts before installing it. All three failed the same way; only the machine that built it had the library. The full set the binary expects: ``` libnatpmp1 libminiupnpc17 libssl3 libboost-chrono1.74.0 libboost-filesystem1.74.0 libboost-program-options1.74.0 libboost-thread1.74.0 ``` In practice everything except `libnatpmp1` is usually present already. ### This is three releases old `v0.13.7` links `libnatpmp` too. `v0.13.3` does not, because NAT-PMP arrived in **v0.13.5**. So every published Linux build since v0.13.5 has had this, and it went unnoticed because the nodes we run were older than the feature that introduced it. ### Documented, not fixed `dobbscoin.info/downloads` and the v0.13.8 release page now list the packages. That is a workaround. Options for an actual fix, none of them chosen here: 1. **Link `libnatpmp` and `libminiupnpc` statically.** Smallest change, removes the two libraries almost nobody has. Boost and OpenSSL stay dynamic. 2. **Link everything static**, as the `depends/` system already does for the Windows build. Biggest binary, fewest surprises. 3. **Build with `--without-natpmp`** and drop the feature from the Linux builds. Cheapest, and loses something that was advertised in v0.13.5. The AppImage is unaffected: it bundles 64 libraries including `libnatpmp.so.1`, verified by extracting it. ### Worth noting for its own sake A dependency that only the build host satisfies is invisible to the people who ship it. Smoke-testing a release binary on a machine that did not build it is the cheap check that catches this class, and it is not currently part of cutting a release.

btcbob referenced this issue from a commit

2026-09-19 03:09:49 +00:00

build: --enable-static-portmap, so a published binary does not need libnatpmp (#45)

btcbob referenced this issue from a commit

2026-09-19 03:10:20 +00:00

Merge branch feat/static-portmap: published binaries stop needing libnatpmp (#45)

btcbob referenced this issue from a commit

2026-09-23 12:54:21 +00:00

build: 0.13.9

btcbob referenced this issue from a commit

2026-09-23 19:03:12 +00:00

depends: miniupnpc 1.9.20140701 -> 2.3.3 (#43)