Cxx turbo modules, upgrading to 0.76.3 from 0.74.2, Android - Module not found at runtime.

[ArindamRayMukherjee]

Hi,

I have been using CXX based turbo modules almost since their first introduction (circa 0.69 IIRC).

I have a few general wishes first

1. The RN upgrade helper should mention of how the CXX turbo module boilerplate changes.
2. The HowTo docs for the older versions seem to vanish, so upgrading the cxx turbo module boilerplate from 0.72 new arch to 0.74 new arch was quite painful as is migrating from 0.74 to 0.76(in progress currently for my project). Could the past docs be kept around please?
3. The HowTo docs do not make explicit a more mature case that involves linking various CXX static/dynamic libraries. Boost is a particularly painful case wherein RN includes a curated version of it, leaving user turbo module code that depends on other parts of boost in a bit of a limbo, requiring careful management how to link the right version of boost without creating a conflict for the ios and android builds. A typical demonstration of how to do this with the major modes of linking cxx libraries of different types would be quite helpful.

Finally the current problem -
Simply following the tutorial does not do the trick for Android for 0.76.3.
I get the error shown in the screen shot attached here.
Here is a reproducer - https://github.com/danceaway-app/cxx-turbo-module-trial.git
(nothing special as you can see in its git history)

The reproducer project is only wired up for turbo modules on Android btw, I didn't do the ios bit since that works in my project.

Cheers

[cortinico]

This is probably related to this bug:

• [0.76] Revert "Include autolinkin.h in OnLoad.cpp only if it exists react-native-releases#667

We're shipping a fix for it in the coming days (0.76.5) so you should probably wait for it

[ArindamRayMukherjee]

[cortinico]

Is tying down the verifiability of the boilerplate from the help docs into a test somewhere a possibility?

Yeah that would be a nice to have, but we currently don't have capacity to develop such an infrastructure.

The RN upgrade helper should mention of how the CXX turbo module boilerplate changes.

What you want here is essentially this:

• RFC0721: Golden Template for create-react-native-library react-native-community/discussions-and-proposals#721

The HowTo docs do not make explicit a more mature case that involves linking various CXX static/dynamic libraries. Boost is a particularly painful case wherein RN includes a curated version of it, leaving user turbo module code that depends on other parts of boost in a bit of a limbo, requiring careful management how to link the right version of boost without creating a conflict for the ios and android builds. A typical demonstration of how to do this with the major modes of linking cxx libraries of different types would be quite helpful.

We won't be able to offer the HowTo docs for that specific scenario. Linking against Boots, as you found out, is tricky, because RN also depends on it. If we were to publish documentation for it, it would get stale really quickly and would be extremely hard to maintain in the long run

[ArindamRayMukherjee]

@cortinico Upgrading to 0.76.5 did not fix this problem, i.e. the basic happy flow functionality of the Cxx turbo modules is broken for Android.
I still get the same error as the screenshot attached up above.
Just following the RN tutorial, nothing special.
I have updated the reproducer at - https://github.com/danceaway-app/cxx-turbo-module-trial.git

Is this better tracked as an issue on react-native?

[ArindamRayMukherjee]

IOS works fine by the way, it's just Android.

I did the boilerplate for wiring in the CXX module for Android quite religiously, but do feel free to throw the book at me if I did something wrong there.

[cortinico]

You're right sorry. For some reason I thought this would fail during build. I'll investigate a bit further and get back to you

[cortinico]

So I've looked into it and the problem is the following: you're not compiling your custom OnLoad.cpp file. You can verify this by adding a random string in that file, and verify that your build is still green (while it should fail).

That is because in your CMake file you're importing the ReactNative-application.cmake file which is using the default app OnLoad.cpp.

I need to further investigate as I recall there was a way with CMake to exclude a previously added source to a target (in this case, the default OnLoad.cpp).

In theory you should be able to update your CMakeLists.txt file as such:

cmake_minimum_required(VERSION 3.13)

# Define the library name here.
project(appmodules)

# This file includes all the necessary to let you build your React Native application
include(${REACT_ANDROID_DIR}/cmake-utils/ReactNative-application.cmake)

# Define where the additional source code lives. We need to crawl back the jni, main, src, app, android folders
file(GLOB input_SRC CONFIGURE_DEPENDS
        OnLoad.cpp
        ${BUILD_DIR}/generated/autolinking/src/main/jni/*.cpp
        ../../../../../shared/NativeSampleModule.cpp)
target_sources(${CMAKE_PROJECT_NAME} PRIVATE OnLoad.cpp)

# Define where CMake can find the additional header files. We need to crawl back the jni, main, src, app, android folders
target_include_directories(${CMAKE_PROJECT_NAME} PUBLIC ../../../../../shared)

the problem is that this will result in a duplicate symbol build failure.

The workaround at the moment are:

1. In your CMakeLists.txt file, do not import ReactNative-application.cmake but copy over the logic. That file is quite long so it will be impractical
2. Use the C++ Module Autolinking. That means that your C++ module will have to live in a separate NPM package and React Native will link it by default. You can search here in the working group for examples on how to do it.
3. Wait for me to come with a better solution (this will be in January due to XMas break).

I'm sorry I couldn't provide a better solution but this requires further investigation.

[ArindamRayMukherjee]

Thank you for investigating @cortinico :)

Your analysis/explanation led me to the simple solution of including the local OnLoad.cpp and deleting the one coming in with the node_modules in a script in package.json called with yarn cleanstall.
A bit hackety-hack but only a bit I think.
I've updated the reproducer at this commit - https://github.com/danceaway-app/cxx-turbo-module-trial/commit/0a97eedbc12d6ab24ddd8e5a680143ac357370ea

Is it a possibility to update the docs with this additional bit? That at least reaches the docs vs reality to a consistent working state.

Keen to know if you come up with a more graceful solution in the new year.
Happy holidays in the mean time!

[cortinico]

Just a small heads up that we just merged:

• fix: Prioritise local cpp (use default as fallback) facebook/react-native#48340

Which should fix your specific setup as well without having to do any manipulation inside the node_modules folder.

[ArindamRayMukherjee]

@cortinico Additional bit that might be interesting for you. I found a way to include boost separately for the turbo module by

1. Downloading boost into a custom directory within the project using another script in package.json
2. Creating one level of indirection in the CMake+Podfile compile toolchain and bringing in boost for static linking for the turbomodule codebase alone.

A bit gnarly but necessary given the boost version included into the RN dependencies are curtailed to exclude everything other than what RN itself needs.

Curious if your insider knowledge of the RN ecosystem says there being a way to do the above?

[cortinico]

For Boost, you can define the REACT_NATIVE_BOOST_PATH env variable to a location where your boost sources will be located. If you then enable build-from-source, the build logic will honor that env variable to allow you to provide your own boost copy:

https://github.com/react-native-tvos/react-native-tvos/blob/fa1add510ccb05dbf2b33686426066deab9c7e06/packages/react-native/ReactAndroid/build.gradle.kts#L61-L64