Fix RCT-Folly build error when use_frameworks! and hermes are both enabled

[Kudo]

Summary

This PR is fixing the build errors on iOS when use_frameworks! and :hermes_enabled are both enabled. There are two errors:

• fmt/compile.h include not found: This PR adds fmt in header search paths.
• undefined symbols _jump_fcontext and _make_fcontext from boost. the two symbols are actually not be unused. because to generate the shared library in dynamic framework mode, LTO (Link-Time-Optimization) is not as powerful as generating a single executable.

Changelog

[iOS] [Fixed] - Fix RCT-Folly build error when use_frameworks! and hermes are both enabled

Test Plan

• CI passed

$ npx react-native init RN069 --version next
# edit RN069/ios/Podfile to enable use_frameworks! and hermes_enabled
# patch node_modules/react-native from both #34011 and this prs' patch
$ pod install
$ yarn ios

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	7,823,334	+0
android	hermes	armeabi-v7a	7,210,541	+0
android	hermes	x86	8,133,971	+0
android	hermes	x86_64	8,114,124	+0
android	jsc	arm64-v8a	9,690,736	+0
android	jsc	armeabi-v7a	8,446,833	+0
android	jsc	x86	9,642,127	+0
android	jsc	x86_64	10,239,294	+0

Base commit: e5c5dcd
Branch: main

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
ios	-	universal	n/a	--

Base commit: e5c5dcd
Branch: main

[Kudo]

cc @dmitryrykun this is to fix another case when use_frameworks and hermes are both enabled. context: reactwg/react-native-releases#21 (reply in thread)

[facebook-github-bot]

@dmitryrykun has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[dmytrorykun]

@Kudo great, thank you!

[cortinico]

Awesome stuff @Kudo 👍

[react-native-bot]

This pull request was successfully merged by @Kudo in 79baca6.

^{When will my fix make it into a release? | Upcoming Releases}

[marcfrankel]

Will this fix be backported to RN 0.68? Or only available in the 0.69 release track?

[mikehardy]

It's possible to do this one via patch-package - it would be part of this one (which was a separate use_frameworks issue)

https://github.com/mikehardy/rnfbdemo/blob/main/patches/react-native%2B0.69.0.patch

Just this part

https://github.com/mikehardy/rnfbdemo/blob/ce416bfaa462e012fa4b4a7fdeab727c34fd7392/patches/react-native%2B0.69.0.patch#L90-L104

[raghav-mylagary]

Looks like this fix introduced a new issue when building to a real iOS device mikehardy/rnfbdemo#10

[mikehardy]

Confirmed - finally got a chance to check this, thank you so much for reporting this and cross-linking @raghavyadavm !

This unfortunately was a workaround for the use_frameworks! + hermes_enabled = true case but the incompatibility of the -U flags with BITCODE_ENABLED has now broken the default case for running on device even if hermes_enabled = false

I have not tested the case where use_frameworks is absent, but I fear it may break as well

@Kudo this is a problem and I'm not sure how to solve it. I thought "well, those symbols are from the boost_context library" (which I discovered after some searching),

• so "maybe switch linker flag to -lboost_context?". Nope.
• "-lboost"? Nope.
• Remove OTHER_LDFLAGS and switch spec.libraries from "c++abi" to "c++abi", "boost" ? Nope.

So I'm a bit lost on how to repair it but I think we're about to get a lot of attention re: the 0.69.1 release

[marcfrankel]

@mikehardy I can confirm I'm also facing this new -U and BITCODE_ENABLED issue after using the suggested patch package

[mikehardy]

Sorry to hear about that of course. It looked like a real advance (Hermes available in use_frameworks context) but...Yep, since react-native 0.69.1 just went out with this I expect to explode in user recognition in 3....2...

[mikehardy]

I'm going to do a revert PR and propose the cherry-pick on reactwg/react-native-releases#24 (comment) - a real repair would obviously be better but I'll just post it up in case it is useful

[marcfrankel]

@mikehardy Yikes sorry to see this is getting ugly. My only concern right now is I wasn't actually on 0.69.1, but rather just patching 0.68.2. Hopefully I'll be able to patch whatever fix is developed

[mikehardy]

I did a fresh app init and and it will build to real devices

• with and without hermes
• with and without flipper
• any use of use_frameworks triggers the error ld: -U and -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) cannot be used together (with or without hermes)

So the patch clearly has a problem, but use_frameworks usage of any kind was already broken on 0.69.0 so believe it or not, this is not a regression. Just a regression in expectation, we thought this would work.

Possible workarounds:

• remove the RCT-Folly part of my patch linked above for 0.69.0 and you can at least do use_frameworks (but no Hermes)
• reverse the RCT-Folly part of the patch and apply it to 0.69.1 and you can do use_frameworks on it (but no Hermes)
• disable bitcode for your iOS build, use 0.69.1 and you can do use_frameworks and use hermes

[Kudo]

thanks for the good catch! i'm afraid there's no easy solution. for bitcode, apple requires all symbols to be defined, so that they can recompile optimized code. the _jump_fcontext from boost context is implemented in ASM and not a boost header only code. hermes executor is tight coupled with boost context (hermes executor -> folly future -> folly fiber -> boost fiber -> boost context)

so far some workaround are:

1. use static framework: use_frameworks! :linkage => :static, that would also benefit from runtime performance.
2. disable bitcode. apple is planning to deprecate bitcode as well.

[mikehardy]

Oh this bitcode disable link is really unexpected!

Xcode no longer builds bitcode by default and generates a warning message if a project explicitly enables bitcode: “Building with bitcode is deprecated. Please update your project and/or target settings to disable bitcode.” The capability to build with bitcode will be removed in a future Xcode release. IPAs that contain bitcode will have the bitcode stripped before being submitted to the App Store. Debug symbols for past bitcode submissions remain available for download. (86118779)

Thanks for that link. I was the under impression that bitcode was how they did app thinning and was a best practice + I have been recommending it and how to work with it in relation to uploading dSYMS for crash reporting systems (like @react-native-firebase/crashlytics see: https://stackoverflow.com/questions/54577202/how-to-run-upload-symbols-to-upload-dsyms-as-a-part-of-xcode-build-process/55796619#55796619) so this is actually big news for me.

I will need to research more but...how are they doing app thinning then? Or are they just no longer doing app thinning? (update: looks like they only have one CPU arch now, so it is not needed https://stackoverflow.com/questions/72543728/xcode-14-deprecates-bitcode-but-why/72552590)

Either way, sounds like the "proper" solution here is actually to advice people that if they want use_frameworks! to work, disable bitcode since that is the future anyway? Then they may use either linkage as well.

We could make a doctor check that looked for use_frameworks && bitcode-enabled combination perhaps and produce an error

This will serve as a workaround in Podfile -

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['ENABLE_BITCODE'] = 'NO'
    end
  end
end

[raghav-mylagary]

Oh this bitcode disable link is really unexpected!

Xcode no longer builds bitcode by default and generates a warning message if a project explicitly enables bitcode: “Building with bitcode is deprecated. Please update your project and/or target settings to disable bitcode.” The capability to build with bitcode will be removed in a future Xcode release. IPAs that contain bitcode will have the bitcode stripped before being submitted to the App Store. Debug symbols for past bitcode submissions remain available for download. (86118779)

Thanks for that link. I was the under impression that bitcode was how they did app thinning and was a best practice + I have been recommending it and how to work with it in relation to uploading dSYMS for crash reporting systems (like @react-native-firebase/crashlytics see: https://stackoverflow.com/questions/54577202/how-to-run-upload-symbols-to-upload-dsyms-as-a-part-of-xcode-build-process/55796619#55796619) so this is actually big news for me.

I will need to research more but...how are they doing app thinning then? Or are they just no longer doing app thinning? (update: looks like they only have one CPU arch now, so it is not needed https://stackoverflow.com/questions/72543728/xcode-14-deprecates-bitcode-but-why/72552590)

Either way, sounds like the "proper" solution here is actually to advice people that if they want use_frameworks! to work, disable bitcode since that is the future anyway? Then they may use either linkage as well.

We could make a doctor check that looked for use_frameworks && bitcode-enabled combination perhaps and produce an error

This will serve as a workaround in Podfile -

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['ENABLE_BITCODE'] = 'NO'
    end
  end
end

Disabling the Bitcode doesn’t seems to be working with libraries like Reanimated. I ended up using the above option 1 which solved the issue

[mikehardy]

Disabling the Bitcode doesn’t seems to be working with libraries like Reanimated. I ended up using the above option 1 which solved the issue

I think (correct me if I'm wrong) the correct version of this statement is:

Disabling Bitcode allowed the compilation and linking to progress farther at which point issues with Reanimated in use_frameworks! with dynamic linkage had a problem, but static linkage appeared to work

The assumption is that bitcode is actually unrelated to a reanimated build issue but the linkage style is?

[raghav-mylagary]

Disabling the Bitcode doesn’t seems to be working with libraries like Reanimated. I ended up using the above option 1 which solved the issue

I think (correct me if I'm wrong) the correct version of this statement is:

Disabling Bitcode allowed the compilation and linking to progress farther at which point issues with Reanimated in use_frameworks! with dynamic linkage had a problem, but static linkage appeared to work

The assumption is that bitcode is actually unrelated to a reanimated build issue but the linkage style is?

Yes you are correct. use_frameworks with static linkage is fixing this issue.

[n1tesh]

It's possible to do this one via patch-package - it would be part of this one (which was a separate use_frameworks issue)

https://github.com/mikehardy/rnfbdemo/blob/main/patches/react-native%2B0.69.0.patch

Just this part

https://github.com/mikehardy/rnfbdemo/blob/ce416bfaa462e012fa4b4a7fdeab727c34fd7392/patches/react-native%2B0.69.0.patch#L90-L104

This Patch does not work on 0.68.2.
Still undefined symbols _jump_fcontext and _make_fcontext error.

With
hermes_enabled => true
use_frameworks! :linkage => :static
BITCODE: YES

[mikehardy]

I think it's important to understand that all work at getting use_frameworks to work with hermes will be focused on 0.69+, I would have no expectation at all that 0.68 or lower will work

[n1tesh]

I think it's important to understand that all work at getting use_frameworks to work with hermes will be focused on 0.69+, I would have no expectation at all that 0.68 or lower will work

Updated to 0.69.1

Still undefined symbols _jump_fcontext and _make_fcontext error.

With
hermes_enabled => true
use_frameworks! :linkage => :static
BITCODE: YES // Tried disabling it as well.
Xcode 13.0

[mikehardy]

@n1tesh that's a very unexpected result. The patch put into 0.69.1 explicitly defines those symbols via linker directives. They are explicit. That makes me think your test is somehow not testing what you think it is testing. That sounds vague and is borderline unhelpful but the point is to triple-check all your steps, make sure you npx react-native-clean-project etc

[rahulgpt1]

Hi Team,
I am new in react native and trying to integrate hermes in our existing react-native project but it gives the compilation error like below but if we disabled hermes then it runs successfully

Undefined symbols for architecture x86_64:
"_jump_fcontext", referenced from:
folly::fibers::FiberImpl::deactivate() in folly(Fiber.o)
folly::fibers::FiberImpl::activate() in folly(SimpleLoopController.o)
"_make_fcontext", referenced from:
folly::fibers::FiberImpl::FiberImpl(folly::Function<void ()>, unsigned char*, unsigned long) in folly(Fiber.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Undefined symbols for architecture x86_64:
"_jump_fcontext", referenced from:
folly::fibers::FiberImpl::deactivate() in folly(Fiber.o)
folly::fibers::FiberImpl::activate() in folly(SimpleLoopController.o)
"_make_fcontext", referenced from:
folly::fibers::FiberImpl::FiberImpl(folly::Function<void ()>, unsigned char*, unsigned long) in folly(Fiber.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Below is the project configuration

react-native: 0.68.2
With hermes_enabled => true use_frameworks! :linkage => :static BITCODE: YES

Please suggest us.

Thanks

[mikehardy]

@rahulgpt1 there is no expectation this will work below react-native 0.69.1

The patch put into 0.69.1 explicitly defines those symbols via linker directives

[rahulgpt1]

@rahulgpt1 there is no expectation this will work below react-native 0.69.1

The patch put into 0.69.1 explicitly defines those symbols via linker directives

Hi Mike,

As you said hermes wouldn't work in RN version 0.68.2, but you people resolved this issue in RN version 0.69.1 so I updated my RN version to 0.69.1 but it still gives the same error undefined symbol for "_jump_fcontext" & "_make_fcontext".

See the attached screenshot:

System Detail:

1. MacOS Monterey (12.2.1)
2. MacBook Pro (M1 Chip)
3. Xcode 13.0

Pod File Configuration Details:

1. use_frameworks! (Not using)
2. modular_headers => true (For some of the pods like below)
   pod 'CNIOLinux', '= 2.20.2',:modular_headers => true
   pod 'CNIODarwin', '= 2.20.2',:modular_headers => true
   pod 'CNIOAtomics', '= 2.20.2',:modular_headers => true
   pod 'CNIOSHA1', '= 2.20.2',:modular_headers => true
   pod 'CNIOHTTPParser', '= 2.20.2',:modular_headers => true
   pod 'CNIOBoringSSL','= 2.9',:modular_headers => true
   pod 'CNIOBoringSSLShims','= 2.9',:modular_headers => true
   pod 'CGRPCZlib', '= 1.0.0-alpha.18',:modular_headers => true
3. Bitcode : (Tried both by enabling and disabling)

Thanks

[mikehardy]

use_frameworks! (Not using)
modular_headers => true (For some of the pods like below)
pod 'CNIOLinux', '= 2.20.2',:modular_headers => true
pod 'CNIODarwin', '= 2.20.2',:modular_headers => true
pod 'CNIOAtomics', '= 2.20.2',:modular_headers => true
pod 'CNIOSHA1', '= 2.20.2',:modular_headers => true
pod 'CNIOHTTPParser', '= 2.20.2',:modular_headers => true
pod 'CNIOBoringSSL','= 2.9',:modular_headers => true
pod 'CNIOBoringSSLShims','= 2.9',:modular_headers => true
pod 'CGRPCZlib', '= 1.0.0-alpha.18',:modular_headers => true

If you are not using use_frameworks!, then you are not on the right issue I think?

This issue is titled: "Fix RCT-Folly build error when use_frameworks! and hermes are both enabled"

Either way, all this modular_headers business is not something I support for react-native-firebase at least, not sure about your dependencies but for react-native-firebase it's use_frameworks! :linkage => :static and that's what we support. The static linkage is important, that allows hermes to compile along with:

Bitcode : (Tried both by enabling and disabling)

Bitcode must be disabled. And that's the future anyway, Xcode 14 no longer supports it, the app store does not accept bitcode, and no platforms use it anymore, but build systems still have it in sometimes. I use the standard Podfile snippet that has been posted in a few places to disable it as a build setting in Podfile postinstall

[rahulgpt1]

Hi Mike,

I have raised a new issue entitled with Undefined symbols for architecture x86_64: "_jump_fcontext" & "_make_fcontext" . Please have a look at #34982

Thanks

[werfar]

I am not able to draw a clear conclusion from this thread, so I just ask (a possible misformulated question); Does firebase >= v 15.0.0 support react-native 0.69+ and hermes, or do we still have to stick with firebase 14.11+ (or put in another way; is it now possible to use use_frameworks! with hermes (in podfile)?)
WF

[mikehardy]

https://github.com/mikehardy/rnfbdemo/blob/main/make-demo.sh --> react-native 0.70.6 + react-native-firebase v16.n.n + hermes

(note @rahulgpt1 you need use_frameworks! :linkage => :static)

[werfar]

thank you @mikehardy for your demo. After some trial and error I got it to work in my project. I noticed there where several changes in the Podfile. Are these temporary solutions or will these be kept in future releases (as far as you know). I also noticed this; $RNFirebaseAsStaticFramework = true. I guess this is important but I cant see where its used/referenced (?). Would you consider this solution production ready?

[mikehardy]

I consider my script the "current gold standard" for whatever the current version of react-native and react-native-firebase is.
Each of those workarounds in the Podfile are necessary as far as I know, and I work actively with the react-native release group to incorporate them in new versions as they are discovered + analyzed

The Podfile variable you mentioned about static frameworks is used internally in react-native-firebase podspec files to alter linking a little bit

[lsl-code]

Hi Team,
I'm making push notifications that can support android 12 or above. react-native-firebase/messaging I saw this website when I upgraded from 11.2.0 to 18.0.0. The project package.json is as follows:

"react": "16.13.1",
"react-native": "0.63.4",
"@react-native-firebase/app": "18.0.0",
"@react-native-firebase/messaging": "18.0.0",

Podfile is as follows:

require_relative '../node_modules/react-native/scripts/react_native_pods'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'

platform:ios, '10.0'

target 'Smart' do
   config = use_native_modules!

   use_react_native!(:path => config["reactNativePath"])

   pod 'IQKeyboardManager'

   target 'SmartTests' do
     inherit! :complete
     # Pods for testing
   end

   # Enables Flipper.
   #
   # Note that if you have use_frameworks! enabled, Flipper will not work and
   # you should disable these next few lines.
   # use_flipper!
   # post_install do |installer|
   # flipper_post_install(installer)
   # end
end

target 'Smart-tvOS' do
   #Pods for SmartHealthUp-tvOS

   target 'Smart-tvOSTests' do
     inherit! :search_paths
     # Pods for testing
   end
end
# Override Firebase SDK Version
$FirebaseSDKVersion = '7.9.0'

There is no problem with the Android upgrade, but there is a "pod install" execution problem with iOS:

1.CocoaPods could not find compatible versions for pod "RNFBApp"

→Solution: platform: ios, '10.0' increased to platform: ios, '13.0'

2.CocoaPods could not find compatible versions for pod "FirebaseCoreExtension"

→Solution: $FirebaseSDKVersion = '7.9.0' increased to $FirebaseSDKVersion = '10.10.0'

3.The Swift pod FirebaseCoreInternal depends upon GoogleUtilities, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set use_modular_headers! globally in your Podfile, or specify :modular_headers => true for particular dependencies.

→Solution: Added use_modular_headers!

and XCode compilation issues:

1."/node_modules/react-native/ReactCommon/yoga/yoga/Yoga.cpp:2285:9 Use of bitwise '|' with boolean operandsCast one or both operands to int to silence this warning"

→Solution: Use the fix prompted by XCode to solve it.

2."/ios/Pods/Headers/Public/React-Core/React/RCTBridge.h:24:1 Unknown type name 'RCT_EXTERN'in file included from"

→Solution: Append the following code to Podfile

post_install do |installer|
     flipper_post_install(installer)
     # NOTE: Change IPHONEOS_DEPLOYMENT_TARGET to 12.4.
     installer.pods_project.targets.each do |target|
       target.build_configurations.each do |config|
         config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '12.4'
         #Close Enable Modules (Translation:Close Enable Modules)
         config.build_settings['CLANG_ENABLE_MODULES'] = 'NO'
       end
     end
     # __apply_Xcode_12_5_M1_post_install_workaround(installer)
end

3."/node_modules/react-native-device-info/ios/RNDeviceInfo/DeviceUID.m:7:1 Use of '@import' when modules are disabled"

→Solution:
1.Enable the modules. Go to the Target > Build Settings and set the Enable Modules (C and Objective-C modules) to YES.
2.Go to build phases -> Compile Sources -> Select the file -> Add compiler flag -fmodules

4."/ios/Pods/FirebaseCore/FirebaseCore/Sources/FIRHeartbeatLogger.m:26:8 Receiver type 'FIRHeartbeatsPayload' for instance message is a forward "

Tried "rm -rf node_modules & rm -rf yarn.lock & yarn install & cd ios & rm -rf Pods & rm -rf Podfile.lock & pod install"
I'm very distressed because I couldn't solve the problem. I suspect it's caused by version mismatch. Do you have any good suggestions?