Report the dlopen failure reason on stderr - #1101
Open
conrade-ctc wants to merge 1 commit into
Open
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1101 +/- ##
==========================================
+ Coverage 87.74% 87.82% +0.08%
==========================================
Files 23 23
Lines 6429 6431 +2
==========================================
+ Hits 5641 5648 +7
+ Misses 788 783 -5
... and 2 files with indirect coverage changes
🚀 New features to boost your workflow:
|
Contributor
|
clang-tidy review says "All clean, LGTM! 👍" |
aaronj0
approved these changes
Sep 2, 2026
aaronj0
left a comment
aaronj0
left a comment
Collaborator
There was a problem hiding this comment.
LGTM! I think updating compiler-research/cppjit#63 to make use of this directly is a more robust (and platform independent) solution
| // message. | ||
| // TODO: Implement callbacks | ||
|
|
||
| // std::cerr, not llvm::errs(): cppyy captures only std::cerr's rdbuf. |
Collaborator
There was a problem hiding this comment.
Suggested change
| // std::cerr, not llvm::errs(): cppyy captures only std::cerr's rdbuf. |
DynamicLibraryManager::loadLibrary got the dlerror() text from platform::DLOpen but only emitted it under LLVM_DEBUG. cppjit's load_library builds its Python error from captured stderr, so the reason was empty. Emit the text to std::cerr; cppjit captures only std::cerr's rdbuf, not llvm::errs(). Paths.cpp already calls ::dlerror() to build this text. Co-developed-with-the-help-of: Claude Code (Fable 5, human in the loop)
conrade-ctc
force-pushed
the
pr-e-dlopen-reason
branch
from
September 2, 2026 13:31
e1a0b15 to
9a9d37d
Compare
Contributor
|
clang-tidy review says "All clean, LGTM! 👍" |
This was referenced Sep 3, 2026
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
3 participants
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.
DynamicLibraryManager::loadLibrary captured the dlerror() text but logged it only under LLVM_DEBUG. cppjit's load_library reads stderr to build its Python error, so it saw an empty reason. This change writes the text to std::cerr, because cppjit captures only std::cerr's rdbuf, not llvm::errs(). Paths.cpp already gets this text from ::dlerror().