Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'react/bridging/LongLivedObject.h' file not found And Could not build module 'ReactCommon' #35664

Closed
sushant115 opened this issue Dec 16, 2022 · 22 comments

Comments

@sushant115
Copy link

sushant115 commented Dec 16, 2022

Description

/Pods/Headers/Public/ReactCommon/ReactCommon/LongLivedObject.h:11:10 'react/bridging/LongLivedObject.h' file not found

/Pods/Headers/Public/React-Core/React/RCTAppSetupUtils.h:30:9 Could not build module 'ReactCommon'

Screenshot 2022-12-16 at 6 52 48 PM

Version

0.70.6

Output of npx react-native info

System:
OS: macOS 13.0.1
CPU: (8) x64 Apple M1 Pro
Memory: 11.91 MB / 16.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 19.2.0 - /usr/local/bin/node
Yarn: 1.22.19 - /usr/local/bin/yarn
npm: 8.19.3 - /usr/local/bin/npm
Watchman: 2022.11.28.00 - /usr/local/bin/watchman
Managers:
CocoaPods: 1.11.3 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 22.1, iOS 16.1, macOS 13.0, tvOS 16.1, watchOS 9.1
Android SDK: Not Found
IDEs:
Android Studio: 2021.2 AI-212.5712.43.2112.8609683
Xcode: 14.1/14B47b - /usr/bin/xcodebuild
Languages:
Java: Not Found
npmPackages:
@react-native-community/cli: Not Found
react: 18.1.0 => 18.1.0
react-native: ^0.70.6 => 0.70.6
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found

Steps to reproduce

Integrated RN version 0.70.6 to existing ios apps
Installed pod vial this command RCT_NEW_ARCH_ENABLED=1 fabric_enabled=1 arch -x86_64 pod install

Snack, code example, screenshot, or link to a repository

Screenshot 2022-12-16 at 6 52 48 PM

@sushant115 sushant115 added Needs: Triage 🔍 Type: New Architecture Issues and PRs related to new architecture (Fabric/Turbo Modules) labels Dec 16, 2022
@cortinico cortinico removed the Type: New Architecture Issues and PRs related to new architecture (Fabric/Turbo Modules) label Dec 16, 2022
@raldred
Copy link

raldred commented Dec 23, 2022

We're seeing this on 0.68.2
Not opted in to new architecture

@daogurtsov
Copy link

Happens to me with new architecture on 0.70.6

@ste7en
Copy link
Contributor

ste7en commented Jan 4, 2023

Happens to me on 0.69.7, not opted in to new architecture nor Hermes

@feige-2011
Copy link

Happens to me with new architecture on 0.71.1

@turboladen
Copy link

turboladen commented Feb 15, 2023

Also seeing it.

❯ yarn react-native info
info Fetching system and libraries information...
System:
    OS: macOS 13.2
    CPU: (10) arm64 Apple M1 Pro
    Memory: 75.94 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.16.0 - /private/var/folders/k9/xm7wlry90z3fjwl909bs1bb80000gp/T/xfs-cc83b2a2/node
    Yarn: 3.4.1 - /private/var/folders/k9/xm7wlry90z3fjwl909bs1bb80000gp/T/xfs-cc83b2a2/yarn
    npm: 9.4.2 - ~/.nvm/versions/node/v16.16.0/bin/npm
    Watchman: 4.9.0 - /opt/homebrew/bin/watchman
  Managers:
    CocoaPods: 1.11.3 - /Users/steve.loveless/.gem/ruby/2.7.6/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1
    Android SDK: Not Found
  IDEs:
    Android Studio: 2022.1 AI-221.6008.13.2211.9514443
    Xcode: 14.2/14C18 - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.18 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: ^18.2.0 => 18.2.0
    react-native: ^0.71.3 => 0.71.3
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

edit: FWIW, I'm just going through the Turbo Modules C++ docs/tutorial; everything worked before going through the App TurboModuleProvider stuff; once I added that, I started getting build failures.

@fobos531
Copy link

fobos531 commented Feb 25, 2023

@cortinico I'm pretty sure the nature of this issue is the same as what this PR fixes. It sounds like the same error, just for a different header file. I tried naively adding the #ifdef __cplusplus declaration analogous to the PR to the LongLivedObject.h in my node_modules folder, but it didn't resolve it for me. @janicduplessis Do you maybe have some insight on how this can be properly integrated?

EDIT: I should note that I get this error if I pass in the -fcxx-modules compiler flag

EDIT2: When I try building the app by adding the #ifdef __cplusplus, I'm getting a bunch of "Redefinition" errors.
CleanShot 2023-02-25 at 11 53 52

@cipolleschi
Copy link
Contributor

Hi there, I'm sorry for this problem.

Can anyone provide a repro I can try on my own?

It's not the first time we see such issues. Our CI has tests for both the Old and the New Architecture, to make sure that it builds, so it should be some edge case that we are not handling properly.

For context:

Now, my gut feeling is that there is something in your configuration that changes the HEADER_SEARCH_PATH of React Native and makes it lose the reference to the ReactCommon base path.

But to verify this, I'll need to reproduce it on a small sample.

@redpanda-bit
Copy link

Hey @cipolleschi I am also facing this issue after following the guide to create a turbo module.

Here is a reproducer: https://github.com/carlosalmonte04/CxxTurboModulesGuide.

It built successfully after commenting out the code you pointed to.

@kaushal9808
Copy link

Hello @cipolleschi , is this issues has been fixed, we are facing the same issue. ?

@cipolleschi
Copy link
Contributor

Hi @kaushal9808, unfortunately I didn't have much time to go deeper in the repro. :(
This week will be tricky, but I'll try to prioritize it next week.

Thank you all for your patience! 🙇

@lc3t35
Copy link

lc3t35 commented Jun 6, 2023

Facing the same issue, using img.ly's PE.SDK with localization : https://img.ly/docs/pesdk/react-native/guides/user-interface/localization/

including #import <RNPhotoEditorSDK/RNPhotoEditorSDK.h> in AppDelegate.mm

adding CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES option and select Yes. Then, search for c++ flags and add -fcxx-modules to both Debug and Release.

without localization and these additions, it build well.

@cipolleschi
Copy link
Contributor

@lc3t35 can you share your Podfile? How did you added the RNPhotoEditorSDK?
In these cases the solution would be to import the dependency with this syntax

// in the Podfile
use_react_native!(
 // ...
)
+ pod 'RNPhotoEditorSDK', [any specific config you need], :modular_headers => true

The modular_headers flag could solve the problem.

@lc3t35
Copy link

lc3t35 commented Jun 8, 2023

Thank you @cipolleschi , I have now this error :

[!] There are multiple dependencies with different sources for `RNPhotoEditorSDK` in `Podfile`:
- RNPhotoEditorSDK (from `../node_modules/react-native-photoeditorsdk`)
- RNPhotoEditorSDK

this error was fixed by using :

pod 'RNPhotoEditorSDK', :path => '../node_modules/react-native-photoeditorsdk', :modular_headers => true

but it still doesn't build :

EXJSIUtils : could not build module 'ReactCommon'
TurboModuleBinding : 'ReactCommon/LongLivedObject.h' file not found

@cipolleschi
Copy link
Contributor

EXJSIUtils

Are you using Expo? Or just some libraries from Expo but the main flow is handled by the RN CLI?

@lc3t35
Copy link

lc3t35 commented Jun 9, 2023

Yes expo in bare mode, so RN mode.

@cipolleschi
Copy link
Contributor

@lc3t35 Ok, so, would you mind open an issue on their repo? Expo does some other things on top of the vanilla RN setup, so it could be that they are applying some changes to the Cocoapods setup that I would not be able to repro.
If they says that's a problem on the RN side, we would need a repro for React Native vanilla in order to work on that.

@cortinico
Copy link
Contributor

As mentioned by @cipolleschi, let's move this issue over to expo:

https://github.com/expo/expo/issues

I'll be closing this but feel free to reopen if the other repo points back to us as a issue in the core of React Native.

@stigi
Copy link
Contributor

stigi commented Jun 13, 2023

I believe the problem is that the header moved. There's a proxy header created here, but it has been excluded from the podspec on purpose. Here's how it looks in v0.71.10:

excluded_files = ENV['USE_FRAMEWORKS'] == nil ?
"react/nativemodule/core/ReactCommon/LongLivedObject.h" :
"react/nativemodule/core/ReactCommon/{LongLivedObject,CallbackWrapper}.h"

If I manually touch up the files that contain the import #import <ReactCommon/LongLivedObject.h> and replace that with #import <react/bridging/LongLivedObject.h> the build succeeds.

For v0.72.0-rc6 the file is moved into it's new package here, but the podspec does not have the exclude anymore.

Some context on why LongLivedObject.h was excluded can be found here: 5c41024

@lc3t35
Copy link

lc3t35 commented Jun 16, 2023

Here is the patch-package for react-native 0.71.3 :

create patches/react-native+0.71.3.patch and add "postinstall": "patch-package"in your package.json.

diff --git a/node_modules/react-native/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleBinding.cpp b/node_modules/react-native/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleBinding.cpp
index 03c65ef..b41b29d 100644
--- a/node_modules/react-native/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleBinding.cpp
+++ b/node_modules/react-native/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleBinding.cpp
@@ -10,7 +10,7 @@
 #include <stdexcept>
 #include <string>
 
-#include <ReactCommon/LongLivedObject.h>
+#include <react/bridging/LongLivedObject.h>
 #include <cxxreact/SystraceSection.h>
 
 using namespace facebook;
diff --git a/node_modules/react-native/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleBinding.h b/node_modules/react-native/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleBinding.h
index 1791d4e..ed4184a 100644
--- a/node_modules/react-native/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleBinding.h
+++ b/node_modules/react-native/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleBinding.h
@@ -9,7 +9,7 @@
 
 #include <string>
 
-#include <ReactCommon/LongLivedObject.h>
+#include <react/bridging/LongLivedObject.h>
 #include <ReactCommon/TurboModule.h>
 #include <jsi/jsi.h>
 
diff --git a/node_modules/react-native/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModule.mm b/node_modules/react-native/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModule.mm
index 1ee5908..8aab28f 100644
--- a/node_modules/react-native/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModule.mm
+++ b/node_modules/react-native/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModule.mm
@@ -22,7 +22,7 @@
 #import <React/RCTModuleMethod.h>
 #import <React/RCTUtils.h>
 #import <ReactCommon/CallInvoker.h>
-#import <ReactCommon/LongLivedObject.h>
+#import <react/bridging/LongLivedObject.h>
 #import <ReactCommon/TurboModule.h>
 #import <ReactCommon/TurboModulePerfLogger.h>
 #import <ReactCommon/TurboModuleUtils.h>

@lc3t35
Copy link

lc3t35 commented Jun 16, 2023

@cortinico as you can see all modules are react-native 0.71.3 related not expo (version 48.0.19 I currently use)
Can you please check if these imports are corrected in upper version of react-native ?

seems to be even removed in 0.72.x : 419025d

@cortinico
Copy link
Contributor

@cortinico as you can see all modules are react-native 0.71.3 related not expo (version 48.0.19 I currently use)
Can you please check if these imports are corrected in upper version of react-native ?

Can you please create a repro on 0.71 or 0.72 which doesn't use Expo and reproduces this issue? Once you have it please open a new issue and link this one, and we can look into it

@cipolleschi
Copy link
Contributor

as you can see all modules are react-native 0.71.3 related not expo (version 48.0.19 I currently use)
Can you please check if these imports are corrected in upper version of react-native ?

@lc3t35 Thanks for the comment, but it doesn't matter whether the modules are react-native 0.71.3: we do some changes on the project settings when Cocoapods run to make sure that the required headers are accessible. Expo could bypass or modify those changes in a way that could potentially hide the header.

As @cortinico was suggesting, if you manage to have a reproducer without Expo, we may be able to investigate the issue. Otherwise, we are a bit blind: we have several jobs in CI which build iOS apps in various configurations and all of them can find the header and they build correctly, so we have no evidences of this problem.

facebook-github-bot pushed a commit that referenced this issue Nov 8, 2023
Summary:
Similarly to #36391 , we found that this import was periodically causing issues for our builds. We applied this patch and found that it is solving the issue, thus raising the PR here.

It may potentially be related to #35664 and #41281

## Changelog:

[IOS] [FIXED] - Unbreak Cocoapods build

Pull Request resolved: #41368

Test Plan: Automated test builds should be able to spot out potential issues.

Reviewed By: javache

Differential Revision: D51117316

Pulled By: cipolleschi

fbshipit-source-id: 5c8ee35ab38539ae1f5556202bb274566adf09b3
Othinn pushed a commit to Othinn/react-native that referenced this issue Jan 9, 2024
…k#41368)

Summary:
Similarly to facebook#36391 , we found that this import was periodically causing issues for our builds. We applied this patch and found that it is solving the issue, thus raising the PR here.

It may potentially be related to facebook#35664 and facebook#41281

## Changelog:

[IOS] [FIXED] - Unbreak Cocoapods build

Pull Request resolved: facebook#41368

Test Plan: Automated test builds should be able to spot out potential issues.

Reviewed By: javache

Differential Revision: D51117316

Pulled By: cipolleschi

fbshipit-source-id: 5c8ee35ab38539ae1f5556202bb274566adf09b3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests