Build fails due to header files missing when using -fcxx-modules flag (AppDelegate.mm)

[uloco]

Description

I can't build the iOS project, always get the error /ios/Pods/Headers/Public/Yoga/yoga/YGNode.h:14:10: 'BitUtils.h' file not found. I tried cleaning up everything, reinstalling pods with repo update etc. etc., didn't work...

Version

0.68.1

Output of npx react-native info

info Fetching system and libraries information...
System:
OS: macOS 12.3.1
CPU: (8) arm64 Apple M1
Memory: 146.02 MB / 16.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 16.13.0 - ~/Library/Caches/fnm_multishells/10309_1650316313370/bin/node
Yarn: 1.22.15 - ~/Library/Caches/fnm_multishells/10309_1650316313370/bin/yarn
npm: 8.7.0 - ~/Library/Caches/fnm_multishells/10309_1650316313370/bin/npm
Watchman: 2022.03.21.00 - /opt/homebrew/bin/watchman
Managers:
CocoaPods: 1.11.3 - /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.4, iOS 15.4, macOS 12.3, tvOS 15.4, watchOS 8.5
Android SDK: Not Found
IDEs:
Android Studio: 2021.1 AI-211.7628.21.2111.8193401
Xcode: 13.3.1/13E500a - /usr/bin/xcodebuild
Languages:
Java: 11.0.14.1 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 17.0.2 => 17.0.2
react-native: 0.68.1 => 0.68.1
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found

Steps to reproduce

I was currently upgrading from 0.66.3 to 0.68.1 and did all the steps in the upgrade helper to do so.
Afterwards the build is not working.

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

[uloco]

I found out this only happens when the -fcxx-modules flag is set in OTHER_CPLUSPLUS_FLAGS. But I need this setting to be enabled because we are using react-native-nordic-dfu which uses @import syntax to import Swift modules. Is there any way to fix this without disabling the flag from a react-native side?

[uloco]

Is this maybe related to cocoapods not correctly linking all the cplusplus related files?

[cortinico]

because we are using react-native-nordic-dfu which uses @import syntax to import Swift modules

Have you considered raising this issue on react-native-nordic-dfu? I suppose they might have other users with this same problem

[uloco]

I will raise an issue there also, but i think this is a general problem. Is it in general not recommended to use this flag in react-native?

[uloco]

When I look into the header files the first one that can't be find is the BitUtils.h file. But the weird thing is, that it is present in the node_modules folder of react-native (ReactCommon...). This BitUtils.h file is referenced from the yoga package. There is a #ifdef __cplusplus in the YGNode.h file in which it trys to load the BitUtils.h. The files are just not in the pods/headers where they should be linked to. Is there maybe a cocoapods setting, which will link the correct cplusplus packages, when this flag is enabled?

[uloco]

FYI I managed to get the build working again by removing all cpp flags and renaming AppDelegate.mm back to AppDelegate.m. I guess this will break other things in the future (maybe the new arch) but at least I can work with this now.

[cortinico]

I guess this will break other things in the future (maybe the new arch) but at least I can work with this now.

Yup that's correct, you won't be able to use the New Architecture with .m

[jkadamczyk]

Hey! Not much help there but, I also have this issue with a different library. I tried adding -fcxx-modules flag and yoga was broken as well in the same file.
The library in question is quite popular one – Segment Analytics.
I was trying to call Segment Track in AppDelegate.mm I think it would fail if I tried to initialise it as well since it depends on the same Header file.

[uloco]

The weird thing is, the missing files are actually inside the node_modules folder but not in the Pods/Headers folder. The headers that are specified in the yoga ifdef __cplusplus part are not linked there correctly. This seems more like a cocoapods issue, doesn't it?

[stage88]

I managed to temporarily fix this by copying the files (which are symbolic links anyway) from ios/Pods/Headers/Private/Yoga/yoga to ios/Pods/Headers/Public/Yoga/yoga, started with BitUtils.h then ended up dragging a few more until it built successfully.

For me this started happening (maybe, still have to confirm but 99% sure) after I installed expo.

[gustavoggs]

I am facing this issue also, It started to happen when I added the flag also. I have an import with @ in my AppDelegate.

[WNemencha]

Facing this issue also, did migrate from Expo 44 (0.66.3) to Expo 45 (0.68.2) last week and it was building fine, did some pod install today and had some issues with @import Firebase (ot: which I solved with #import <Firebase/Firebase.h>) but then this issue started to appear.

I'm using the AppDelegate.mm file, have passed the -fcxx-modules and -fmodules flags, and also checked that Enable Modules is set to YES in both debug/release builds.

[pedpess]

First, my iOS build was not recognising AppDelegate.mm file, like the file name was never changed during the React Native upgrade.

I had then to go to XCode and change it there so it would reflect in project.pbxproj because XCode was still referencing .m over .mm. Probably a thing to add as a tip for the community @cortinico?

Now I have the same issue as @WNemencha has with @import Firebase, which I changed to #import <Firebase/Firebase.h> and it worked! thanks for sharing 🙏🏻

[cortinico]

I had then to go to XCode and change it there so it would reflect in project.pbxproj because XCode was still referencing .m over .mm. Probably a thing to add as a tip for the community @cortinico?

Not entirely sure how we can improve the docs to mention this? 🤔 We clearly state that you need to rename your AppDelegate.m to AppDelegate.mm. Any suggestion here?

[pedpess]

@cortinico I did as the doc said and renamed the file on VSCode, but XCode didn't pick the new name even after a fresh build cleaning everything the build failed 😕

To make it work I had to change the file name on XCode instead and just then the "project.pbxproj" indexed it correctly

[cortinico]

but XCode didn't pick the new name even after a fresh build cleaning everything the build failed 😕

Ah I see. Thanks for explaining. @cipolleschi what's your take here. Perhaps we can clearly mention in the doc that the file should be renamed inside Xcode or there is a way to regenerate the xcodeproj so that the .mm file is picked up.

[EdwardDrapkin]

I was able to solve this by creating an Objective C class with static methods that called to my problematic module (in this case, Iterable), and then importing and calling that from the Objective C++ file.

[spylefkaditis]

@EdwardDrapkin would you be able to share that?

[cipolleschi]

Ah I see. Thanks for explaining. @cipolleschi what's your take here. Perhaps we can clearly mention in the doc that the file should be renamed inside Xcode or there is a way to regenerate the xcodeproj so that the .mm file is picked up.

@cortinico @pedpess In the migration steps here, there is an info box saying exactly that! :D

Use Xcode to rename existing files to ensure file references persist in your project. You might need to clean the build folder (Project → Clean Build Folder) before re-building the app. If the file is renamed outside of Xcode, you may need to click on the old .m file reference and Locate the new file.

---

On the other note, there is no compatibility between Swift and Objective-C++. The solution proposed by @EdwardDrapkin is the proper and most rigorous one.

---

@uloco Are you perhaps using Expo? I have seen that many people that has this issue is because they are using Expo.
Could you also provide a streamlined repo with the bare minimum code that reproduces the issue so we can look into that?

[uloco]

@cipolleschi Yes we are using expo for in app purchases only, so the project itself was setup without expo and we added the bare library afterwards.

I needed to enable the -fcxx-modules flag not because of expo though, because of the react-native-nordic-dfu library which uses @import syntax. I can try to create a repo for you guys, with the -fcxx-modules flag set I guess?

Thanks :)

[cipolleschi]

I needed to enable the -fcxx-modules flag not because of expo though, because of the react-native-nordic-dfu library which uses @import syntax. I can try to create a repo for you guys, with the -fcxx-modules flag set I guess?

Yep, ideally something like we can clone, install dependencies, build and see it failing! 👍

Given that the expo is highly related to this, we could also ask @Kudo if he has any insight on this.

[pedpess]

@cortinico @pedpess In the migration steps here, there is an info box saying exactly that! :D

Aha! It's indeed there @cipolleschi :D tks. This page should be marketed more because I was not even aware it existed. I guess most of us are using the RNUpgradeHelper and reading what are the warnings there that we should be aware of before migrating to newer versions

[WNemencha]

Beware that bringing .mm files into your project (especially expo ones) will bring hazard and failures into the mix :')

[uloco]

@cipolleschi So I could reproduce this issue and react native v0.68.2 simply does not have the files linked correctly after init. If you create a project with npx react-native init RN68new --version 0.68.2 you can see that not all headers got linked in ios/Pods/Headers/Public/Yoga/yoga/. Even when I reinstall node_modules and pods, it does not get linked.

In v0.69.4 this is no longer the case so I guess it is fixed. Would be great to have a fix for 0.68.2 too though.

At first this is no problem but after installing expo, the problem start happening. I did install expo just by running npx install-expo-modules

I created a repro for this so you can see for your self. See: https://github.com/uloco/repro-rn-header-files-missing

[Kudo]

i think the two commits are necessary for 0.68 to fix the problem: 43f831b and c2088e1#diff-d4330f88e3e4a96cd4853ac5ecd225d1808ad70713d381984db19f834cc21bf3R54

if 0.69.4 works for you, is it possible for you to upgrade to 0.69.4?

[uloco]

We are in the midst of a very big long running migration so no time for upgrading react native atm. But in the end of course we want to do the upgrade. But: We don't want to use react 18 for now, since it introduce a whole bunch of bugs right now...

[julestruong]

Any news on this ? it's been 4 months ^^
I'm having the same issue there , can't wait to use new arch

[cipolleschi]

@julestruong on which react native version are you? Can you update to the latest patch of your current version and try again?

[julestruong]

I'm on 68.5

[shamilovtim]

Any updates on this? If react native is going to keep using Objective-C++ then having compatibility with -fcxx-modules is mandatory.

[uloco]

You can use the flag on v69+. I'm on latest react native now and it works.

[cipolleschi]

@julestruong sorry for the late reply, I haven't seen these comments. We are not supporting 0.68 anymore, could you try to update and verify that the problem is still there?

---

@shamilovtim which version are you using? do you have a repro for that?

If that's due to Expo or to some other third party library, we can't add the flag in React Native as it could be due to those and adding it could break someone else workflow.

If it is something we can reproduce and debug, we may think of offering some utility to set up the flag properly, but our CIs are building fine a good amount of vanilla scenarios, so it shouldn't be a React Native issue.

[shamilovtim]

@cipolleschi using "react-native": "0.71.2" and adding the -fcxx-modules flag to the Pods target and building with Xcode using the xcworkspace I receive the following error:

In the React-Core pod: "Declaration of 'atomic_bool' must be imported from module 'std.atomic' before it is required." This feels like a race or a cyclical import but I'm not sure.

Additionally, every time I run npx pod-install the Pods target seems to get regenerated and wipe out the -fcxx-modules flag. The flag seems to be inherently incompatible with react native, both via its constant removal, and via the React pod being incompatible with it.

[cipolleschi]

I'm not a C++ expert, but, by looking at RCTMessageThread.h, there is no #import <atomic>. So I guess that it is right that, if we enable Cxx Modules we actually have to import the <atomic> module before using it.

What I think is happening is that, when we do not use modules, all the required symbols are available in the global space, so React Native is able to properly link against std::atomic_bool. By adding the -fcxx-modules flag, we enter in a stricter regime and the import is required.

We have a similar problem when enabling use_frameworks! for iOS.

Additionally, every time I run npx pod-install the Pods target seems to get regenerated and wipe out the -fcxx-modules flag. The flag seems to be inherently incompatible with react native, both via its constant removal, and via the React pod being incompatible with it.

This is a bug I discovered yesterday and I think that it has already landed in main. Sorry for that. 😅

[shamilovtim]

Should the various RN pods natively support -fcxx-modules? I think that it's more realistic to support CPP modules (which is an additive change) rather than not being able to support simple legacy code from iOS like @import Foundation

[cipolleschi]

We could, but right now React Native minimum support is for C++ 17 and Cxx modules are a feature of C++ 20, so we can't enforce it right now. As soon as Meta decides to move the minimum support to C++ 20, we could plan the work to do so.

In this half I'm doing a bunch of work to ensure that use_frameworks! will work. This could bring compatibility with C++ modules also (but I'm not sure about that) or at least move us in the right direction. Unfortunately, the framework is quite big and intricated, so it's not trivial to support them. This effort requires planned work.

[cipolleschi]

I think we can close this: React Native now supports use_frameworks! in both static and dynamic configurations

[andresev]

I found out this only happens when the -fcxx-modules flag is set in OTHER_CPLUSPLUS_FLAGS. But I need this setting to be enabled because we are using react-native-nordic-dfu which uses @import syntax to import Swift modules. Is there any way to fix this without disabling the flag from a react-native side?

Any fix for this? I'm currently using 'react-native-nordic-dfu' and I'm running into this problem after setting the -fcxx-modules into Build Settings -> Other C++ Flags. Can't seem to find a workaround. Need the flag for it to work.

[cipolleschi]

which version of React native are you using?

[andresev]

@cipolleschi Currently, 72.3

[cipolleschi]

Can you create a reproducer using this template so I can have a look at it more thoroughly? 🙏

[andresev]

I've created an issue here:
Salt-PepperEngineering/react-native-nordic-dfu#14