Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[java-interop] try using RTLD_NOW|RTLD_LOCAL
Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=4002003&view=logs&j=65486226-8c87-5153-e73a-d57909d6ac16&t=d3853860-5663-595d-ac96-d10e64bcf850 The story so far: 2cf8ac9 conjectured that requiring RTLD_LAZY|RTLD_LOCAL was causing the macOS Designer tests to fail, and allowed the caller to provide the desired flags *and log them*. Eventually, we got a log: 5 [monodroid] # jonp: java_interop_load_library: path=`/Library/Frameworks/Xamarin.Android.framework/Versions/11.1.99.69/lib/xamarin.android/xbuild/Xamarin/Android/lib/host-Darwin/libxa-internal-api.dylib` 5 [monodroid] # jonp: java_interop_load_library flags= RTLD_NOW Unfortunately, 2cf8ac9 had a bug in which it didn't check for RTLD_LOCAL; all we know is that RTLD_NOW was specified, and that possibly RTLD_LOCAL was specifed (maybe); RTLD_GLOBAL was NOT used. Also interesting from the log file is what was *missing*: no mentions of `java_interop_get_symbol_address` were present! Thus, the next conjecture: whatever codepath was trying to lookup `java_interop_jnienv_get_java_vm` within 2cf8ac9 *isn't* using `java_interop_get_symbol_address()` to do so, and is instead relying on the normal dynamic linker (somehow). Next test: let's once again "ignore" the `flags` value provided to `java_interop_load_library()`, and instead always use RTLD_LOCAL|RTLD_NOW. Perhaps that's the magic pixie dust needed?
- Loading branch information