fix: drop -Wl,--no-undefined from Android shim build #55
Merged
SineVector241 merged 2 commits intoAvionBlock:masterfrom Apr 11, 2026
Merged
fix: drop -Wl,--no-undefined from Android shim build #55SineVector241 merged 2 commits intoAvionBlock:masterfrom
SineVector241 merged 2 commits intoAvionBlock:masterfrom
Conversation
The --no-undefined guard added alongside -lm exposed a pre-existing bug in
upstream libopus's ARM DNN dispatch table: opus/dnn/arm/arm_dnn_map.c
unconditionally references compute_activation_{c,neon} and
compute_conv2d_{c,neon}, but on armeabi-v7a those definitions are gated
behind a NEON feature detection that does not fire for the Android arm32
build, so the symbols are never compiled. arm64 is unaffected because NEON
is mandatory on AArch64.
Previously these unresolved references were silently tolerated by the
linker and left as undefined symbols in the .so (a latent bug that would
only surface at dlopen time if the DRED/deep-PLC code path was exercised).
--no-undefined promoted them to hard link errors and broke the arm32 job.
Drop the guard to restore the arm32 build. The -lm fix — which is the
actual root cause of the original Unity IL2CPP DllNotFoundException on
arm64 — is retained.
Contributor
Author
|
…ndroid Regenerates and replaces every prebuilt native binary under OpusSharp.Natives/runtimes: - android-arm, android-arm64, android-x64, android-x86 (libopus.so) - linux-arm, linux-arm64, linux-x64, linux-x86 (opus.so) - osx-arm64, osx-x64 (opus.dylib) - win-arm64, win-x64, win-x86 (opus.dll) - ios/libopus.xcframework (device + simulator static libs, headers, Info.plist, and the meson.build header-bundle descriptors) The primary motivation is fixing the Android arm64 libopus.so. The previous binary was compiled without linking libm, so its DT_NEEDED list contained only libdl.so and libc.so. On device the Android dynamic linker refused to load it the moment a managed caller tried to construct an OpusEncoder or OpusDecoder, and the failure surfaced through P/Invoke as the generic DllNotFoundException: Unable to load DLL 'opus' dlopen failed: library "opus" not found making it look like the file was missing from the APK when in fact it was present and correctly placed in lib/arm64-v8a/. The rebuilt arm64 binary now declares libm.so as NEEDED alongside libdl.so and libc.so, satisfying every math symbol opus pulls in from the C runtime and allowing the library to load successfully on Android. All other runtimes are regenerated from the same build run so every platform ships a matching version of the underlying opus codec and associated shim exports, rather than mixing old binaries with the new Android build.
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
2 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.
Summary
Follow-up to the previous
-lmfix. The-Wl,--no-undefinedguard I added as belt-and-braces exposed a pre-existing latent bug in upstream libopus's ARM DNN dispatchtable, breaking the
armeabi-v7aCI job:ld.lld: error: undefined symbol: compute_activation_c
▎ ▎ ▎ referenced by arm_dnn_map.c:55 ... in archive libopus.a
▎ ▎ ▎ ld.lld: error: undefined symbol: compute_activation_neon
▎ ▎ ▎ ld.lld: error: undefined symbol: compute_conv2d_c
▎ ▎ ▎ ld.lld: error: undefined symbol: compute_conv2d_neon
opus/dnn/arm/arm_dnn_map.cunconditionally references both C and NEON variants of the DNN compute functions. On arm64 those definitions are unconditional (NEON ismandatory on AArch64), so the link succeeds. On armeabi-v7a they're gated behind a NEON feature detection that doesn't fire correctly for the Android arm32 build, so
the symbols are never compiled.
Before my previous PR, these unresolved references were silently tolerated by the linker and left as undefined entries in the dynamic symbol table — a latent bug that
would only blow up at
dlopentime if the DRED / deep-PLC code path was exercised on arm32.--no-undefinedpromoted that latent breakage into a hard link error.Fixing the upstream
xiph/opusfeature-detection is out of scope for this repo. The pragmatic move is to drop the guard and restore the arm32 build to its previous(working-for-practical-purposes) state. The
-lmfix — which is the actual root cause of the Unity IL2CPPDllNotFoundExceptionon arm64 devices — is retained.Changes
-Wl,--no-undefinedfrom the Android "Build with shim" link step.-lm(unchanged from the previous PR).Follow-up (not in this PR)
Upstream
xiph/opusshould be reported for thearm_dnn_map.carmeabi-v7a symbol gap — the map file should#ifdefits entries the same way the definitions are gated.Out of scope here.