Repository navigation
loader: find the runtime relative to our own module, not just by name - #23
Merged
Merged
Conversation
dylib_loader only ever called LoadLibraryA/dlopen with a bare name, so the OS
search path alone decided whether librediffusion was found. That works for a
system install, for LD_LIBRARY_PATH, and for score's AppImage (AppRun prepends
every <root>/support/* that holds shared libs) -- but nowhere else:
- Loaded from a Max or TouchDesigner plugin, the host's folder is Max's or
TD's, never the plugin's, so a runtime shipped inside the plugin package is
unreachable. score-addon-onnx hit exactly this and solved it with
ossia::get_module_folder(); we had no equivalent.
- On Windows nothing puts <root>/support/librediffusion on the DLL search
path at all: score's launcher.cpp sets QML2_IMPORT_PATH and a baked-in
SCORE_ENVIRONMENT but never touches PATH/SetDllDirectory, and
create-app-windows.sh has no support/ handling. The Linux-only AppRun logic
has no counterpart there.
So resolve the module that contains this code (GetModuleHandleEx / dladdr) and
also look beside it, and in "support/librediffusion" next to it -- the layout
the release bundles already use. The plain-name attempt stays FIRST so existing
deployments keep resolving exactly as before; the new paths are a fallback.
Verified on Linux with a library present in neither ldconfig nor any system
path: found via <module>/support/librediffusion and its symbol called.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq
jcelerier
force-pushed
the
release/sat-2026-09
branch
from
September 15, 2026 21:41
35759ef to
2a230dc
Compare
jcelerier
added a commit
to ossia/score-addon-librediffusion
that referenced
this pull request
Oct 7, 2026
librediffusion's dylib_loader resolved the runtime by bare name only, so it was
found only when the OS search path already covered it. That is never the case for
the Max and TouchDesigner externals, whose plugin folder is not on the search
path, nor on Windows where nothing put {RootPath}/support on the DLL search path.
The fix is consumer-side: it lives in a header that compiles into whatever links
librediffusion, so librediffusion.dll/.so carries none of it and this addon only
picks it up via the submodule pointer.
jcelerier/librediffusion#23
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq
jcelerier
added a commit
to ossia/score-addon-librediffusion
that referenced
this pull request
Oct 7, 2026
librediffusion's dylib_loader resolved the runtime by bare name only, so it was
found only when the OS search path already covered it. That is never the case for
the Max and TouchDesigner externals, whose plugin folder is not on the search
path, nor on Windows where nothing put {RootPath}/support on the DLL search path.
The fix is consumer-side: it lives in a header that compiles into whatever links
librediffusion, so librediffusion.dll/.so carries none of it and this addon only
picks it up via the submodule pointer.
jcelerier/librediffusion#23
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq
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
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.
dylib_loaderonly ever calledLoadLibraryA/dlopenwith a bare name, so the OSsearch path alone decided whether librediffusion was found. That works for a system
install, for
LD_LIBRARY_PATH, and for score's AppImage (whoseAppRunprepends every<root>/support/*holding shared libs) — but nowhere else:the plugin's, so a runtime shipped inside the plugin package is unreachable.
score-addon-onnxhit exactly this and solved it withossia::get_module_folder(); wehad no equivalent.
<root>/support/librediffusionon the DLL search path at all.(Root cause since found and fixed upstream: score's
addSupportLibraries()calledAddDllDirectorywithoutSetDefaultDllDirectories, making the whole block a no-op —Fix five packaging/deployment defects found while building the SAT tool suite ossia/score#2281.)
So resolve the module containing this code (
GetModuleHandleEx/dladdr) and also lookbeside it, and in
support/librediffusionnext to it — the layout the release bundlesalready use. The plain-name attempt stays first, so existing deployments resolve
exactly as before; the new paths are only a fallback.
Verified on Linux against a library present in neither
ldconfignor any system path:found via
<module>/support/librediffusionand its symbol called.Note for consumers: the fix is consumer-side — this header compiles into whatever
uses librediffusion, so
librediffusion.dll/.soitself carries none of it and theconsumers must be rebuilt.
🤖 Generated with Claude Code
https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq