Guidance on directories that allow dlopen

[jim.b...@couchbase.com]

I'm having a pretty hard time getting this to work but I have a SQLite extension, which is loaded via dlopen, that is packaged into an APK.  It comes from a package that I am developing and I have noticed a few things.  This is via .NET 8, so gradle is entirely unused and the .NET tooling attempts to mimic what is being done.  So things like `useLegacyPackaging` are not available, but there is an older variant of this called android:extractNativeLibs which .NET honors by doing the following:

- If extractNativeLibs is true (which appears to be the default?) then jniLibs are stored in the APK compressed, and they end up in the native libs directory.  My SQLite extension filename does not begin with lib, though, so it doesn't get extracted and I cannot extract it there after the fact because the directory is readonly!  This is quite irritating and the subject of this thread

- If extractNativeLibs is false, then jniLibs are stored in the APK uncompressed and I can use the magic dlopen syntax to get at them from within the APK.

However, the latter doesn't work for API 22, which is currently our minSdkVersion, so the only choice is extracting native libs.  But where can I extract them to?  I tried cache, files, code_cache, and /data/app-lib/<package> but for the first few dlopen returns null, but with an error code of 0.  The final path (app-lib) returns null with an error code of 20 (not a directory).  Is my only choice to rename the library filename itself so that it can get magically auto extracted or is there somewhere I can put this extension?

[enh]

if you want this to work on all api levels, yes, i think you will need
to fix the names.

> --
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/8115ce7a-8e81-4a91-b45d-72a305962559n%40googlegroups.com.

[jim.b...@couchbase.com]

Oddly even after renaming, and seeing that it is extracted, dlopen STILL fails (returns null) with a 0 error code from the native lib directory.  Any information on why that might be?

[Florian Mayer]

Did you check dlerror?

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/491a60b4-4176-4c2f-9bb2-a3fba8f73537n%40googlegroups.com.

[enh]

yeah, dlerror() would be my next step. we try to be pretty detailed in
that (and the detailed error UnsatisfiedLinkError messages you see
from java are mostly just our dlerror() content).

if you're really in trouble, wrap.sh combined with LD_DEBUG lets you
grind things to a halt by dumping far too much. (i really need to
improve that.)

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAJAyTCBpE_D_jfxYrhUQoMEWvH9C5%2BTUNgsudiVS6AC8WYtG5A%40mail.gmail.com.

[jim.b...@couchbase.com]

My apologies for not realizing dlerror was a thing.  It gave me this message:

> dlopen failed: empty/missing DT_HASH in "/data/app/com.couchbase.vectorsearch.tests-1/lib/x86_64/libCouchbaseLiteVectorSearch.so" (built with --hash-style=gnu?)

So the next step is figuring out WHY this is getting built this way.....I have another native library that loads without issue that I think builds the same way.  And in fact this happens on API 22 but not API 24.  I think I know why actually.  I had set Android ABI level to 23 in the native build script for this library....which probably triggered the newer hash behavior. 

[enh]

On Wed, Mar 27, 2024 at 3:25 PM 'jim.b...@couchbase.com' via
android-ndk <andro...@googlegroups.com> wrote:
>
> My apologies for not realizing dlerror was a thing. It gave me this message:
>
> > dlopen failed: empty/missing DT_HASH in "/data/app/com.couchbase.vectorsearch.tests-1/lib/x86_64/libCouchbaseLiteVectorSearch.so" (built with --hash-style=gnu?)
>
> So the next step is figuring out WHY this is getting built this way.....I have another native library that loads without issue that I think builds the same way. And in fact this happens on API 22 but not API 24. I think I know why actually. I had set Android ABI level to 23 in the native build script for this library....which probably triggered the newer hash behavior.

exactly. if you target an old api level, we'll create _both_ sysv and
gnu hashes (so it works everywhere, but takes full advantage of new
devices). if you target a new enough api level that we're guaranteed
it supports gnu hashes, we only generate those. but then obviously you
can't use that library on a device that didn't support gnu hashes.

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/b9d8d8cd-6184-4e6e-a6f1-074ede1b02bdn%40googlegroups.com.

[enh]

actually, for anyone else with a similar problem who _can't_ just fix
the relevant code to output dlerror(), recent versions of Android let
you enable logging for all dlopen()/dlsym() failures on any debuggable
app: https://android.googlesource.com/platform/bionic/+/master/android-changes-for-ndk-developers.md#enable-logging-of-dlopen_dlsym-and-library-loading-errors-for-apps-available-in-android-o