Node >= 23.8 exports its bundled zstd: native addons' ZSTD_* calls bind to Node's copy on Linux
Since Node added zstd (23.8 / 24.x, process.versions.zstd), the node executable exports its ZSTD_* symbols (292 in Node 24). On Linux the executable comes first in the global lookup scope, so any native addon that compiles zstd in with default visibility, or links a shared libzstd, gets its ZSTD_* calls resolved to Node's copy, not its own. LD_DEBUG=bindings shows it. It's harmless only while the versions happen to match and you only use public, stable API.
It also affects third-party .so files loaded by an addon that carry their own (often older) zstd: their exported entry points bind to Node's copy while their internal helpers stay local. That mixes versions on the same context, which can crash or hang.
Fix for your own code: compile the vendored zstd with -fvisibility=hidden, and define ZSTDLIB_VISIBLE / ZSTDERRORLIB_VISIBLE empty (zstd's headers force default visibility otherwise). Check nm -D --defined-only addon.node | grep -c ZSTD == 0, and at runtime use dladdr() on a ZSTD function pointer to confirm it lives in your .node.
For vendor libraries you can't rebuild: RTLD_DEEPBIND fixes zstd but can rebind operator new/delete to the vendor's own copies (allocator mixing). Consider dlmopen(LM_ID_NEWLM) isolation instead, and test it. macOS two-level namespaces don't have this problem.
Verified in Docker (arm64): Node 22.23 exports zstd 1.5.7 too, so this isn't only 23.8+; check process.versions.zstd, not the version number. Node 20 exports none: there, an addon's vendored zstd only gets interposed if another library puts ZSTD_* in the global scope. A plain require() of another addon is RTLD_LOCAL and doesn't; process.dlopen(..., RTLD_GLOBAL) does. Use LD_BIND_NOW=1 with LD_DEBUG=bindings to see every binding (about 120 ZSTD/HUF/FSE in one addon); lazy binding shows only the functions called. And a test that checks ZSTD_versionNumber() can't tell your copy from Node's when they're the same version. Compare dladdr(&ZSTD_fn).dli_fbase with an address in your own object instead. On macOS, two-level namespace keeps the addon's own copy, so this can't be reproduced there.
Confirmed on x86_64 Linux, Node 24.21. With the fix (-fvisibility=hidden plus empty ZSTDLIB_VISIBLE and ZSTDERRORLIB_VISIBLE on both the zstd unit and the C++ unit that includes zstd.h), the addon exports 0 ZSTD/HUF/FSE symbols and makes 0 external ZSTD bindings under LD_BIND_NOW. Two more points. (1) A vendor .so with its own older zstd gets mixed even when its code never calls zstd: function-pointer tables in its data (the block-compressor table) are relocated at load time to Node's copies, and these show up even without LD_BIND_NOW. (2) The same thing happens in plain executables, with no Node involved. If you link a system -lzstd before the vendor .so, the vendor's exported entry points bind to the system copy and its internals stay local (here 68 external, 48 own). With -lzstd after it, your executable's own ZSTD calls go to the vendor's old copy. Neither order is clean: link your zstd statically with hidden symbols (or -Wl,--exclude-libs,ALL with libzstd.a).
Follow-up on closing the addon's export surface: -fvisibility=hidden on the C++ unit alone still left 61 dynamic exports on Linux, because libstdc++ templates instantiated from headers keep default visibility. Adding a linker version script that exports only napi_register_module_v1 and node_api_module_get_api_version_v1 (local: *;) took it to 2 exports. On macOS the equivalent is -exported_symbols_list, and set the install name to @rpath/<addon>.node instead of the temporary build path. Check with nm -D --defined-only (Linux) or nm -gU (macOS) in CI so it can't regress.