C++ STL Library on Android does not support exception_ptr

[mrousavy]

Description

For some reason, std::exception_ptr is broken in react-native.

I have added this code to react-native/ReactAndroid/src/main/jni/react/jni/OnLoad.cpp:

__android_log_print(ANDROID_LOG_ERROR, "EXCEPTION", "Running exception test...");
try {
  throw std::runtime_error("Test exception");
} catch (...) {
  auto eptr = std::current_exception();
  try {
    std::rethrow_exception(eptr);
  } catch (const std::exception& e) {
    __android_log_print(ANDROID_LOG_ERROR, "EXCEPTION", "Caught std::exception: %s", e.what());
  } catch (...) {
    __android_log_print(ANDROID_LOG_ERROR, "EXCEPTION", "Caught unknown exception!!");
  }
}

And it logs

11-29 17:50:54.049 31176 31176 E EXCEPTION: Running exception test...
11-29 17:50:54.054 31176 31176 E EXCEPTION: Caught unknown exception!!

If you run the same code on iOS (replace log with NSLog), it works as expected:

11-29 17:50:54.049 31176 31176 E EXCEPTION: Running exception test...
11-29 17:50:54.054 31176 31176 E EXCEPTION: Caught std::exception: Test exception

So for some reason, the Android C++ lib fails to properly rethrow std::exception_ptr. ❌

iOS uses libc++ since ever.

Android uses libc++ since 2015, and apparently used libstdc++ (from GNU) before 2015 - could it be that libstdc++ is still used today somehow?
From what I'm seeing in RN's build.gradle, it correctly uses libc++:

react-native/packages/react-native/ReactAndroid/build.gradle.kts

Line 535 in 91e217f

"-DANDROID_STL=c++_shared",

Anyways... The code above does not work as expected. I think I read somewhere that exception_ptr does not work on ARMv5 since it needs some compare instruction that isn't available there, but afaik my device is ARMv8.

I have confirmed that;

• ✅ It works in a blank Android C++ app
• ✅ It works on iOS
• ❌ It fails in a blank react-native Android app

Steps to reproduce

1. Create a clean new app (npx create-expo-app@latest)
2. Run npx expo prebuild
3. Enable "build react-native from source" (by following these instructions)
4. Add the above code to OnLoad.cpp
5. Run npx expo android
6. In adb, see exception_ptr not properly being castable

React Native Version

0.76.2

Affected Platforms

Runtime - Android

Output of npx react-native info

info Fetching system and libraries information...
System:
  OS: macOS 15.0.1
  CPU: (12) arm64 Apple M2 Pro
  Memory: 240.17 MB / 32.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 18.18.0
    path: ~/.nvm/versions/node/v18.18.0/bin/node
  Yarn:
    version: 1.22.19
    path: ~/.nvm/versions/node/v18.18.0/bin/yarn
  npm:
    version: 10.8.1
    path: ~/.nvm/versions/node/v18.18.0/bin/npm
  Watchman:
    version: 2024.11.11.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.16.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.1
      - iOS 18.1
      - macOS 15.1
      - tvOS 18.1
      - visionOS 2.1
      - watchOS 11.1
  Android SDK:
    API Levels:
      - "28"
      - "30"
      - "31"
      - "33"
      - "33"
      - "34"
      - "35"
    Build Tools:
      - 30.0.3
      - 31.0.0
      - 33.0.0
      - 33.0.1
      - 33.0.2
      - 34.0.0
      - 34.0.0
      - 35.0.0
    System Images:
      - android-33 | Google APIs ARM 64 v8a
      - android-34 | Google Play ARM 64 v8a
    Android NDK: 25.2.9519653
IDEs:
  Android Studio: 2024.2 AI-242.23339.11.2421.12550806
  Xcode:
    version: 16.1/16B40
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.13
    path: /opt/homebrew/opt/openjdk@17/bin/javac
  Ruby:
    version: 2.7.6
    path: /Users/mrousavy/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 15.1.2
    wanted: ^15.1.2
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.76.3
    wanted: 0.76.3
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

Stacktrace or Logs

11-29 17:50:54.049 31176 31176 E EXCEPTION: Running exception test...
11-29 17:50:54.054 31176 31176 E EXCEPTION: Caught unknown exception!!

Reproducer

https://github.com/mrousavy/react-native-exception_ptr-bug

Screenshots and Videos

No response

[react-native-bot]

Warning

Could not parse version: We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.76.2.

[react-native-bot]

Warning

Could not parse version: We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.76.2.

[mrousavy]

The CMakeLists.txt of the project where I added the code to OnLoad.cpp to also enables exceptions:

react-native/packages/react-native/ReactAndroid/src/main/jni/react/jni/CMakeLists.txt

Lines 11 to 14 in 91e217f

	add_compile_options(
	-fexceptions
	-Wno-unused-lambda-capture
	-std=c++20)

I also added -frtti to those options and rebuilt the app, but it still doesn't work.

[NickGerleman]

could it be that libstdc++ is still used today somehow?

Nope. We are using libc++. When we bumped to NDK 26, this got bumped to LLVM 17. IIRC latest beta NDK uses libc++ based on LLVM 19.

All of the build logic we control should also have RTTI enabled I think. I could imagine weirdness happening if a library is using static STL, and RN is using shared STL (so we have different copies of exception types/ODR issues), or if NDK is setting some special flags that XCode isn't. IIRC libc++ had some different ways of being able to implement RTTI, which we do not fuss with ourselves.

[mrousavy]

hm, I can't seem to pinpoint it. It's definitely broken in a blank app created with the expo 52 template bootstrapper.

[cortinico]

@mrousavy have you tried on a vanilla Android App without React Native?

[mrousavy]

@cortinico Yep, in a blank new Android C++ template it works:

[cortinico]

@cortinico Yep, in a blank new Android C++ template it works:

We would have to diff the compilation flag you're using for your native-lib.cpp vs the one used for React Native OnLoad.cpp file. The latter are listed here:

react-native/packages/react-native/ReactAndroid/cmake-utils/ReactNative-application.cmake

Lines 53 to 67 in 67bff87

	target_compile_options(${CMAKE_PROJECT_NAME}
	PRIVATE
	-Wall
	-Werror
	# We suppress cpp #error and #warning to don't fail the build
	# due to use migrating away from
	# #include <react/renderer/graphics/conversions.h>
	# This can be removed for React Native 0.73
	-Wno-error=cpp
	-fexceptions
	-frtti
	-std=c++20
	-DLOG_TAG=\"ReactNative\"
	-DFOLLY_NO_CONFIG=1
	)

[mrousavy]

I added all of those compile options to the CMakeLists.txt file in my blank new Android project, and it also works 🤔

12:44:33.814 EXCEPTION                E  Running exception test...
12:44:33.814 EXCEPTION                E  Caught std::exception: Test exception

[mrousavy]

I also added the options from here:

react-native/packages/react-native/ReactAndroid/build.gradle.kts

Lines 529 to 547 in 67bff87

	externalNativeBuild {
	cmake {
	arguments(
	"-DREACT_COMMON_DIR=${reactNativeRootDir}/ReactCommon",
	"-DREACT_ANDROID_DIR=$projectDir",
	"-DREACT_BUILD_DIR=$buildDir",
	"-DANDROID_STL=c++_shared",
	"-DANDROID_TOOLCHAIN=clang",
	"-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON")
	targets(
	"reactnative",
	"jsi",
	"hermestooling",
	"jsctooling",
	)
	}
	}
	ndk { abiFilters.addAll(reactNativeArchitectures()) }

..and it still works. My guess is that it's caused by some of the libraries being linked having a different C++ STL shipped with them?

react-native/packages/react-native/ReactAndroid/cmake-utils/ReactNative-application.cmake

Lines 70 to 81 in 67bff87

	find_package(ReactAndroid REQUIRED CONFIG)
	add_library(jsi ALIAS ReactAndroid::jsi)
	add_library(reactnative ALIAS ReactAndroid::reactnative)
	find_package(fbjni REQUIRED CONFIG)
	add_library(fbjni ALIAS fbjni::fbjni)
	target_link_libraries(${CMAKE_PROJECT_NAME}
	fbjni # via 3rd party prefab
	jsi # prefab ready
	reactnative # prefab ready
	)

[mrousavy]

I verified that my changes actually worked by replacing -fexceptions with -fno-exceptions in CMake and then the build failed because try cannot be used with exceptions.

What I found weird is that it still prints the correct exception message after I set fno-rtti - is that expected? 🤔

[cortinico]

My guess is that it's caused by some of the libraries being linked having a different C++ STL shipped with them?

FBJNI definitely ships with a libc++ in shared linking:
https://github.com/facebookincubator/fbjni/blob/4c7cdd7cae7ced72aacd12e4129eb9b00b7146d6/build.gradle#L56

We'll have to make sure the NDK version used is the same as we recently updated fbjni, hermes, and RN to use NDK 27. If you happen to use RN 0.76 (on NDK 26) but a recent version of fbjni (build with NDK 27) that could be reason

[mrousavy]

Well I am using react-native 0.76.3 - so that's probably pinning a proper fbjni version, no? That should be NDK 26.

https://github.com/mrousavy/react-native-exception_ptr-bug

[mrousavy]

I'll try to upgrade to RN 0.77

[cortinico]

Have you tried on a non-expo project? Also Fresco could be the culprit here

[mrousavy]

Yes, Nitro's example/ is non-expo - this is where I found this bug.

I'm upgrading to RN 77 right now (mrousavy/nitro#383)

[cortinico]

I'm upgrading to RN 77 right now (mrousavy/nitro#383)

Let me know if this solves it however 77 RC0 is pretty unstable

[mrousavy]

Just created a blank new RN 0.77.0-rc.0 react-native app with the community CLI (so no expo), added the exception code from above to the OnLoad.cpp func, enabled build by source, and it also fails here:

[cortinico]

Just created a blank new RN 0.77.0-rc.0 react-native app with the community CLI (so no expo), added the exception code from above to the OnLoad.cpp func, enabled build by source, and it also fails here:

Great, then I have no idea why this is happening. Not sure how to help further.
I guess I would go the build from source way, trying to do the same try-catch inside RNTester and selectively commenting out build logic to understand what could be causing this.

I also checked the Android NDK and Google Issue tracker, but there is no mention of anything like that

[mrousavy]

Thanks for your help so far Nico! I'll try what I can do, I spent a few hours too many on this already so I'm not sure how far I can take debugging this.

[mrousavy]

What's the deal with SoLoader - do we still need that? I thought it's only for pre-Android 23, and we're past that now.
Can we just rely on the default System.loadLibrary(..), or is SoLoader still needed in react native?

I have a feeling that SoLoader's lib merging thingy might cause some issues here...

[mrousavy]

Didn't we change the second arg to SoLoader.init(..., THIS_ONE) in RN 0.76?
It was false before, now it's the mapping in OpenSourceMergedSoMapping.

Might be the cause of the issue..? 👀

[cortinico]

Didn't we change the second arg to SoLoader.init(..., THIS_ONE) in RN 0.76?
It was false before, now it's the mapping in OpenSourceMergedSoMapping.

Yeah we changed now because we implemented Native Library Merging:
react-native-community/discussions-and-proposals#816

Is std::exception_ptr working on 0.75? If so that could be the culprit.
We need SoLoader exactly to handle the merging of the native libraries

[mrousavy]

Ok I just tried in RN 0.75, and it also doesn't work there: Caught unknown exception. hm.

[cortinico]

Ok I just tried in RN 0.75, and it also doesn't work there: Caught unknown exception. hm.

Ok so at least is not the So Merging that caused this. Still the whole SoLoader infrastructure might affect this, but I'm not sure how given that SoLoader doesn't bring in any native code.

[NickGerleman]

Here's a deep dive on how LLVM matches these: https://github.com/llvm/llvm-project/blob/3c83054bec3326ccf338eeda56e67e8cd83a3b2a/llvm/docs/ExceptionHandling.rst#trycatch

And here is where it rethrows: https://github.com/llvm/llvm-project/blob/ca3180ad6e39304177deac112bd78739d85fe32b/libcxx/src/support/runtime/exception_pointer_cxxabi.ipp#L58

Notably, libc++ with NDK does not use libunwind, and instead uses some Android specific library? And from code, this may impact behavior.

I would recommend creating an issue on the NDK repo, as it may gain more traction (and I think is closer to the source of the bug).

[mrousavy]

I would recommend creating an issue on the NDK repo, as it may gain more traction (and I think is closer to the source of the bug).

But it worked in a blank Android app, it only fails in a blank react-native app 🤔

I'll try to use the same NDK version as in react-native to confirm that it is not just an NDK version issue.

[NickGerleman]

Last factor I could think of… does it happen in a blank Android app using shared stl?

[mrousavy]

Yep, as mentioned here, I created a blank Android app and copied the compile & build options from build.gradle & CMake over, including "-DANDROID_STL=c++_shared".

Still worked there.

[ospfranco]

Ha, I just ran into this.

Leaving a message here for visibility but there is definitely something broken and no mention on the internet of this behavior.

[sergio-nsk]

The OP asked about this issue on StackOverflow - std::rethrow_exception not catchable with catch (const std::exception&) in Android NDK.

If I could I would close this issue as invalid. This is not an issue of the library, the behavior is expected, this is the invalid OP's code that relies on implementation defined behavior.

Some std::rethrow_exception implementations copy an exception object from stack to some stack independent storage.

std::rethrow_exception

It is unspecified whether a copy is made. If a copy is made, the storage for it is allocated in an unspecified way.

support.exception#propagation-10

It is unspecified whether a copy is made, and memory for the copy is allocated in an unspecified way.

The OP catches the exception of unspecified type catch (...) i.e. std::exception_ptr is void* pointer to the exception object. std::rethrow_exception can't deduce the type of the copied thrown exception and rethrows an exception of an unspecified type that can't be caught by the catch (const std::exception& e). The OP must catch const std::exception& to be able to rethrow std::exception.

[mrousavy]

@sergio-nsk so how would the correct code look like then?

Assuming I want to use std::exception_ptr and pass it around freely, then get the exception's message again at a later point? (using this for a Promise implementation)

[sergio-nsk]

Imagine what you can do with an exception object in the catch (...) block. Right, nothing. You should not assume that you may do later something more than nothing. The standard allows implementation defined behavior. You can't get the exception's message in the catch (...) block, you should not assume that you will get the message in a rethrown unspecified/untyped/unknown exception.

so how would the correct code look like then?

try {
  throw std::runtime_error("Test exception");
} catch (const std::exception& e) {
  auto eptr = std::current_exception();
  try {
    std::rethrow_exception(eptr);
  } catch (const std::exception& e) {
    __android_log_print(ANDROID_LOG_ERROR, "EXCEPTION", "Caught std::exception: %s", e.what());
  } catch (...) {
    __android_log_print(ANDROID_LOG_ERROR, "EXCEPTION", "Caught unknown exception!!");
  }
}

[mrousavy]

Did you try your code?

In a blank new Android app, this code works as expected (catches the std::runtime_error as a const std::exception&, then rethrows it and goes into the second catch (const std::exception&))

In a blank new React Native app (0.76.5), adding this code to node_modules/react-native/ReactAndroid/src/main/jni/react/jni/OnLoad.cpp (and enabling build from source), does NOT work as expected - the first throw runtime_error is not even caught as an const std::exception&! 😅

Afaik I used the same NDK version, Shared C++ STL, and same gradle versions, but I'd need to double-check all of that to confirm.

If I could I would close this issue as invalid. This is not an issue of the library, the behavior is expected

I disagree. I think this is a bug in react-native.

[mrousavy]

Could it be possible that some library react-native depends on has different symbols or typeinfos for std::exception..?

[ospfranco]

Here is a comment saying that on hermes std::exception has a different typedef, maybe that is causing the issue:

software-mansion/react-native-reanimated#6773 (review)

[sergio-nsk]

Did you try your code?

I don't need to do that when I see an invalid code.

In a blank new Android app...
In a blank new React Native app...

This behavior is expected, they use different C++ runtimes.

[mrousavy]

@sergio-nsk did you read my reply? Throwing a std::runtime_error does not work as expected.

try {
  throw std::runtime_error("test");
} catch (const std::exception&) {
  // do nothing
}

This crashes the app because the runtime_error is never caught.

I am not Bjarne Stroustrup, but I believe this is not how C++ should work.

[sergio-nsk]

@sergio-nsk did you read my reply? Throwing a std::runtime_error does not work as expected.

try {
  throw std::runtime_error("test");
} catch (const std::exception&) {
  // do nothing
}

Which reply? You have never shown such code. You have shown a different one

  try {
    std::rethrow_exception(eptr);
  } catch (const std::exception& e) {

[mrousavy]

Which reply? You have never shown such code. You have shown a different one

That's your code, lol.
I said in my comment above that your code doesn't work.

But we're going off-topic here. The behaviour is not working as expected, there's a bug, and it's not "invalid". I'll continue my investigations to see why this is happening soon.

[tmikov]

Can anyone please run ldd on the different libraries in their RN app exhibiting the problem and post the output?

[kraenhansen]

I took a bit of time to try to pin-point the root cause of this.

I used the rn-tester app to reproduce this:

1. Checkout this repo at a specific version tag.
2. Cleaning the repo from old artifacts: git clean -fdx
3. Install dependencies: yarn
4. Add this to the top of the JNI_OnLoad implementation in react-native/packages/ReactAndroid/src/main/jni/react/jni/OnLoad.cpp:

   __android_log_print(ANDROID_LOG_ERROR, "EXCEPTION", "Running exception test...");
   try {
     throw std::runtime_error("Test exception");
   } catch (const std::exception& e) {
     __android_log_print(ANDROID_LOG_ERROR, "EXCEPTION", "Caught std::exception: %s", e.what());
   } catch (...) {
     __android_log_print(ANDROID_LOG_ERROR, "EXCEPTION", "Caught unknown exception!!");
   }

• Build and run the Android app: cd packages/rn-tester && yarn android
• Verify the output via logcat: adb logcat -s "EXCEPTION"

Results

tag	prints
v0.77.0-rc.4	Caught unknown exception!! 🔴
v0.76.0	Caught unknown exception!! 🔴
v0.75.4	Caught std::exception: Test exception 🟢

@cortinico

Ok so at least is not the So Merging that caused this. Still the whole SoLoader infrastructure might affect this, but I'm not sure how given that SoLoader doesn't bring in any native code.

I'm not sure we can acquit "so merging" just yet.
Reading https://github.com/fbsamples/android-native-library-merging-demo I see no caveat around limitation in libc++ features or alike, but the jni_lib_merge.c which eventually calls the OnLoad of the library is a C file and therefore isn't built with the -std=c++20 flag (or any other c++ features?):

react-native/packages/react-native/ReactAndroid/src/main/jni/first-party/jni-lib-merge/CMakeLists.txt

Line 19 in 44705fe

add_compile_options(-fexceptions -Wall)

I tried adding -frtti to ☝️ branched off v0.76.0 but that didn't help.

Testing with "so merging" disabled

Is there an "easy" way to revert or disable the "so merging" behavior to test the hypothesis that this is the culprit?
I already tried simply commenting out the target_marge_so line here (which just crash the app):

react-native/packages/react-native/ReactAndroid/src/main/jni/react/jni/CMakeLists.txt

Line 27 in 44705fe

target_merge_so(reactnativejni)

[kraenhansen]

@tmikov can you help craft a command I can easily run on my Mac?

I tried ldd on the libreactnative.so (using ldd from the Android emulator via adb shell), but that errors with a linker error:

// Running `ldd $PWD/libreactnative.so`
        linux-vdso.so.1 => [vdso] (0x7980b16000)
CANNOT LINK EXECUTABLE "linker64": library "libfbjni.so" not found: needed by main executable

This is the result of running llvm-objdump -p on the libreactnative.so:

llvm-objdump -p /Users/kraen.hansen/Repositories/react-native/packages/rn-tester/../react-native/ReactAndroid/build/intermediates/merged_native_libs/debug/mergeDebugNativeLibs/out/lib/arm64-v8a/libreactnative.so

/Users/kraen.hansen/Repositories/react-native/packages/rn-tester/../react-native/ReactAndroid/build/intermediates/merged_native_libs/debug/mergeDebugNativeLibs/out/lib/arm64-v8a/libreactnative.so:     file format elf64-littleaarch64

Program Header:
    PHDR off    0x0000000000000040 vaddr 0x0000000000000040 paddr 0x0000000000000040 align 2**3
         filesz 0x00000000000001f8 memsz 0x00000000000001f8 flags r--
    LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
         filesz 0x000000000133dbf0 memsz 0x000000000133dbf0 flags r-x
    LOAD off    0x000000000133dbf0 vaddr 0x0000000001341bf0 paddr 0x0000000001341bf0 align 2**14
         filesz 0x00000000000586e8 memsz 0x0000000000059410 flags rw-
    LOAD off    0x00000000013962d8 vaddr 0x000000000139e2d8 paddr 0x000000000139e2d8 align 2**14
         filesz 0x0000000000000e40 memsz 0x00000000000187f0 flags rw-
 DYNAMIC off    0x00000000013659f0 vaddr 0x00000000013699f0 paddr 0x00000000013699f0 align 2**3
         filesz 0x0000000000000200 memsz 0x0000000000000200 flags rw-
   RELRO off    0x000000000133dbf0 vaddr 0x0000000001341bf0 paddr 0x0000000001341bf0 align 2**0
         filesz 0x00000000000586e8 memsz 0x0000000000059410 flags r--
EH_FRAME off    0x00000000006e0ba8 vaddr 0x00000000006e0ba8 paddr 0x00000000006e0ba8 align 2**2
         filesz 0x00000000000b028c memsz 0x00000000000b028c flags r--
   STACK off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**64
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-
    NOTE off    0x0000000000000238 vaddr 0x0000000000000238 paddr 0x0000000000000238 align 2**2
         filesz 0x00000000000000b0 memsz 0x00000000000000b0 flags r--

Dynamic Section:
  NEEDED       libandroid.so
  NEEDED       libfbjni.so
  NEEDED       libjsi.so
  NEEDED       liblog.so
  NEEDED       libdl.so
  NEEDED       libm.so
  NEEDED       libc++_shared.so
  NEEDED       libc.so
  SONAME       libreactnative.so
  FLAGS        0x0000000000000008
  FLAGS_1      0x0000000000000001
  RELA         0x000000000051d748
  RELASZ       0x0000000000077430
  RELAENT      0x0000000000000018
  RELACOUNT    0x00000000000015e6
  JMPREL       0x0000000000594b78
  PLTRELSZ     0x00000000000830a0
  PLTGOT       0x000000000136e7e0
  PLTREL       0x0000000000000007
  SYMTAB       0x00000000000002e8
  SYMENT       0x0000000000000018
  STRTAB       0x00000000000f05b4
  STRSZ        0x000000000042d192
  GNU_HASH     0x00000000000bca58
  INIT_ARRAY   0x0000000001369998
  INIT_ARRAYSZ 0x0000000000000058
  FINI_ARRAY   0x0000000001369988
  FINI_ARRAYSZ 0x0000000000000010
  VERSYM       0x00000000000ae1f8
  VERNEED      0x00000000000bc9e4
  VERNEEDNUM   0x0000000000000003

Version References:
  required from libdl.so:
    0x00050d63 0x00 05 LIBC
  required from libm.so:
    0x00050d63 0x00 03 LIBC
  required from libc.so:
    0x00050d63 0x00 02 LIBC
    0x050d693e 0x00 04 LIBC_N

It does list libc++_shared.so as "NEEDED": Desired and expected.

[cortinico]

Is there an "easy" way to revert or disable the "so merging" behavior to test the hypothesis that this is the culprit?
I already tried simply commenting out the target_marge_so line here (which just crash the app):

@kraenhansen nope sadly there is no easy way to do so. You'll have to build from source, revert all the OBJECT library in CMake to be SHARED and use the old SoLoader.init() method.