[BUG]"dlopen failed: empty/missing DT_HASH/DT_GNU_HASH", but already has DT_GNU_HASH #1866
Comments
|
We can Reproduce it by the description in this issue: #1865 |
|
although it's "only" a warning, i think is your real problem. 0x5858585858585858 doesn't look remotely like a a DT_* constant, so i suspect you've corrupted your ELF file... (you did mention that you were doing some post-processing. i suggest trying to load the ELF file "fresh" from the linker, to confirm that it's the post-processing that's corrupting it.) |
|
It's most likely a bug that patchelf introduced. I will write a C/C++ compiler driver wrapper to inject |
|
@enh-google @leleliu008 , thanks. |
|
@enh-google |
because it's different code? having written toybox's readelf for the device myself, and having been somewhat involved in bionic's dynamic linker too, i can say they're very different. (i'd be curious to know what |
|
re.txt I could not use Here is the file: |
if you're on an old version of Android, you won't have it; it was added in Android R: https://android.googlesource.com/platform/system/core/+/master/shell_and_utilities/README.md here's Android U: where the only complaints are: and which llvm-readelf shows as the file is 66824 bytes long, so there's an off-by-one there, and i think it's in our readelf, so i'll fix that. anyway... your .so file's dynamic section looks fine: those seem like the right entries, in the right order, with a single DT_NULL at the end. the string table follows, and although there are large sections of 'X'es in the ELF file (corresponding to the 0x58585858'58585858 that the dynamic linker complained about), there's nothing down here near the end of the file. okay, time to actually try this on an arm64 device! (there will now be a short intermission while i find a suitable device, build for it, flash it, and test it...) |
|
hmm... your libbz2.so with sha256 ac03f5e33e6c90edeed67646588c2d068f4d868f058cb6f432161589528b3b05 dlopen()s fine for me on AOSP master. what version of Android were you having trouble on? |
Factor out the existing section header/program header/note section bounds checks to ensure they all behave the same (rather than program headers being the odd one out) and so they all have much more detailed (and convincing) error messages. Bug: android/ndk#1866
Description
It is related to this issue: #1865, after I solve the
sonameproblem.Also with the libbz2.so, my app crash when starting up:
But I checked the
libbz2.soand found:Below is part of the elf info:
Affected versions
r23
I’ve used the latest NDK version: 25.2.9519653, and the problem still exists.
Canary version
No response
Host OS
Mac
Host OS version
macOS 13.2.1
Affected ABIs
arm64-v8a
Build system
CMake
Other build system
No response
minSdkVersion
21
Device API level
29
The text was updated successfully, but these errors were encountered: