Rewrite the addon's libchdb path whatever the engine calls it - #80
Merged
Conversation
The engine release check found this on its first run: chdb-node cannot load its
own addon against chdb-core v26.7.0 on macOS. Both arm64 and x86_64 fail with
ERR_DLOPEN_FAILED while both Linux shards pass.
install_name_tool -change matches the dependency by its exact recorded name, and
that name comes from the engine's install_name, which changed:
v26.5.x libchdb.so
v26.7.0 @rpath/libchdb.so
The script only knew the first spelling. -change succeeds and does nothing when
the old name does not match, so the addon kept @rpath/libchdb.so, which it has no
LC_RPATH to resolve, and dlopen failed at require() time — the build itself was
green, and the otool -L output the script prints showed the unrewritten path to
anyone who looked.
Both spellings are rewritten now, and the result is verified rather than assumed:
a dependency this script cannot resolve fails the build, naming what it found. The
next install_name change should stop the build with a clear message instead of
producing an addon that cannot load.
Checked on macOS by rewriting a built addon's dependency to @rpath/libchdb.so to
reproduce the no-op, confirming the fix restores @loader_path/../../libchdb.so,
that a second run is idempotent, and that an unknown third spelling exits 1. A
full local rebuild against v26.7.0 was not possible — node-gyp 9.3.1 does not run
under Node 26 on this machine — so CI is the first end-to-end build. The v3 suite
does pass against v26.7.0's engine with the existing addon, so nothing else about
that version troubles the binding.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
The verification could pass on an addon that cannot load, in two ways. `grep -qv "$TARGET"` treats the dots in @loader_path/../../libchdb.so as wildcards, so @loader_path/ab/cd/libchdb.so matched and was accepted even though neither rewrite had applied. And the pipeline's status came from that last grep, so otool failing on a missing or unreadable addon produced no output, no match, and a clean exit — the case the check exists to catch, passing. It now reads the dependency out and compares it as a string. One assertion covers all of it: otool failing, no libchdb dependency at all, more than one, and a path that merely resembles the target. pipefail goes in as well. Checked on macOS against four addons: the @rpath spelling is rewritten, a second run is idempotent, @loader_path/ab/cd/libchdb.so is rejected where the old check accepted it, and a missing addon is rejected where the old check passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
@wudidapaopao please review it |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #79.
The engine release check found this on its first run: chdb-node cannot load its own
addon against chdb-core v26.7.0 on macOS. Both arm64 and x86_64 fail with
ERR_DLOPEN_FAILED; both Linux shards pass.install_name_tool -changematches the dependency by its exact recorded name, andthat name comes from the engine's
install_name, which changed:The script only knew the first spelling.
-changesucceeds and does nothing whenthe old name does not match, so the addon kept
@rpath/libchdb.so— which it hasno
LC_RPATHto resolve — and dlopen failed atrequire()time. The build itselfstayed green, and the
otool -Loutput the script already prints showed theunrewritten path to anyone who happened to read it.
Both spellings are rewritten now, and the result is verified instead of assumed: a
dependency this script cannot resolve fails the build and names what it found. The
next
install_namechange should stop the build with a clear message rather thanproduce an addon that cannot load.
What was checked
On macOS, by rewriting a built addon's dependency to
@rpath/libchdb.sotoreproduce the no-op:
@loader_path/../../libchdb.so@executable_path/libchdb.so) exits 1 with thedependency printed
A full local rebuild against v26.7.0 was not possible — node-gyp 9.3.1 does not run
under Node 26 on this machine — so CI is the first end-to-end build of the addon
against that engine. The v3 suite does pass against v26.7.0's engine with the
existing addon (41 files, 476 tests), so nothing else about that version troubles
the binding; the loader path was the whole of it.
🤖 Generated with Claude Code
Note
Rewrite both known
libchdbinstall name spellings in the macOS addon build scriptlibchdb.soand@rpath/libchdb.sowhen callinginstall_name_tool, so the rewrite succeeds regardless of which spelling the build toolchain records.@loader_path/../../libchdb.so, exiting with status 1 and a diagnostic message if not.set -o pipefailand quotes variables throughout for robustness.Macroscope summarized 2a87342.