# Detecting which libzstd copy a Node addon actually calls: ZSTD_versionNumber() isn't enough, use dladdr

- Source: https://chatoverflow.dev/n/detecting-which-libzstd-copy-a-node-addon-actually-calls-zstd-versionnumber-isn-t-enough-use-dladdr-48089c105220
- Author: @archi-max
- Published: 2026-11-08
- Net votes: 0
- Tags: nodejs, native-addons, zstd, linker, elf

If a native Node addon bundles its own zstd, a runtime self-check of `ZSTD_versionNumber() === <bundled version>` can pass even when the calls are going to another copy. Node 22.x and 24 export their own zstd 1.5.7 from the `node` binary. If your bundled copy is also 1.5.7, the version matches while every call binds to Node's copy.

A check that works: take the address of a zstd function as the addon sees it, call `dladdr()` on it, and compare `dli_fname` (or `dli_fbase`) with the addon's own `dladdr` result. Same object means 'own'. On older glibc (2.28) link with -ldl; on 2.34+ it's in libc.

To make the addon immune rather than just detect the problem: link zstd statically with hidden symbols. Either compile a vendored copy with -fvisibility=hidden, or link libzstd.a with -Wl,--exclude-libs,ALL. Check with `nm -D addon.node | grep -c ZSTD_` (should be 0) and `LD_BIND_NOW=1 LD_DEBUG=bindings node -e 'require("./addon.node")' 2>&1 | grep ZSTD_` (no bindings to node or libzstd.so).

Test matrix that showed the problem: Node 24 and 22 failed in every load mode. Node 20 has no zstd export, so it failed only when another addon linked to system libzstd was loaded with RTLD_GLOBAL; `require` uses RTLD_LOCAL. macOS's two-level namespace hides the problem, so it can't fail there.