Resolve undefined symbols across the executable's global scope#1
Merged
Merged
Conversation
elf-verify checked each bundled library's undefined symbols only against that library's own DT_NEEDED chain. At runtime the dynamic loader instead resolves every loaded object against a single global scope made up of the executable and its whole dependency closure, so a library's imports can be satisfied by a sibling library the executable also loads without any direct DT_NEEDED link between them. This produced false "undefined symbol" reports for libraries that import from a sibling — e.g. a libEGL.so.1 shim whose gl* imports are provided by the sibling libGLESv2.so.2 (apps-repo PR #190 flagged ~275 gl* symbols as undefined on every firmware). After resolving each bundled library against its own DT_NEEDED chain, also resolve any remaining undefined symbols against the executable's global scope. Genuinely missing libraries and symbols are still reported. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011jY7WzoWeU9TWRBhWJ2Wbq
The global-scope symbol resolution fix changes ipk-verify's output (libraries whose imports are satisfied by a sibling no longer report false undefined-symbol errors). Bump the affected crates so the new behaviour ships as a distinct release. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011jY7WzoWeU9TWRBhWJ2Wbq
This was referenced Jun 26, 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
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.
Problem
ipk-verifyflags hundreds of false "undefined symbol" errors for libraries whose imports are actually provided by a sibling library the executable also loads.This surfaced on apps-repo PR #190 (
org.webosbrew.bridge-64to32): the compat check reportsrequired lib libEGL.so.1as:x:on every firmware, with ~275gl*symbols (glActiveTexture,glBindBuffer, …) listed as undefined — whilelibGLESv2.so.2passes.Root cause
Analysing the bundled binaries:
libEGL.so.1is a thin EGL shim with 275 undefinedgl*imports and aDT_NEEDEDof onlylibgles_bridge_core.so+libc.so.6— it does not listlibGLESv2.so.2.gl*functions are defined by the sibling bundledlibGLESv2.so.2.DT_NEEDEDs both libs (withRPATH=$ORIGIN/lib), so at runtime the loader places both into one global symbol scope andlibEGL'sgl*references bind tolibGLESv2. It works.But
verifychecked each bundled library in isolation: it only struck off symbols reachable through that library's ownDT_NEEDEDchain (recursive_resolve_symbolsfollowslib.needed). SincelibEGLdoesn't directly depend onlibGLESv2, thegl*imports were never resolved → false "undefined" reports. The stock firmwarelibEGL.so.1only ever exportedegl*, so matching against firmware failed too.Fix
After resolving each bundled library against its own
DT_NEEDEDchain, also resolve any remaining undefined symbols against the executable's global scope — the dependency closure rooted at the executable'sDT_NEEDED— mirroring the real dynamic loader (common/verify/src/ipk/component.rs). Genuinely missing libraries and symbols are still reported.Verification
Ran the rebuilt
webosbrew-ipk-verifyagainst the realorg.webosbrew.bridge-64to32IPK across all 13 firmware datasets:required lib libEGL.so.1required lib libwayland-egl.so.1required lib libpulse.so.0/libpulse-simple.so.0libpulsecommon-15.0.sois in alib/pulse-15.0/subdir that isn't on the search path)The fix is surgical: it clears the sibling-scope false positives while leaving real missing-library/missing-symbol problems intact.
Added regression tests in
packages/ipk-verify/tests/global_scope.rs(sibling-provided symbol passes; truly-missing symbol still fails). Existing tests unaffected.Bumps
verify-lib0.1.2 → 0.1.3 andipk-verify0.1.4 → 0.1.5.🤖 Generated with Claude Code
Generated by Claude Code