-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
Hermes does not compile for iOS #43241
Comments
Hey @CyberMew, it looks like the latest changes to our debugger API are not source compatible with older versions of React Native. We do maintain source compatibility for JSI, but we don't generally guarantee compatibility for the Hermes C++ API. That said, we are working towards a stable C-based binary interface that will allow new versions of Hermes to be dropped into older versions of RN. Given that this change is relatively small, it may be possible to work around it by making some minor source modifications, or building without debugging enabled. |
hi @CyberMew, I believe that file has been removed in newer React Native versions. And as @neildhar mentioned, our C++ API is not source compatible with older RN versions. That said, the compilation problem is a simple one to fix. One workaround you can do is by modifying places that read |
Thank you all for the information. May I know to which version of RN is this supported back? I am using the latest stable RN version 0.73.4 as mentioned (fresh project), do I have to switch to 0.74 RC for this to work out of the box? From the pod logs for 0.73.4 it is already pulling from main branch, so shouldn’t it already be the latest Hermes code? |
I just tried the workaround to replace the 2 occurrences in node_modules/react-native/ReactCommon/hermes/inspector-modern/InspectorState.cpp, it did kinda work, but it still failed with another error: [ 96%] Building CXX object API/hermes/CMakeFiles/libhermes.dir/cdp/DebuggerDomainAgent.cpp.o Going to ios/Pods/hermes-engine/API/hermes/hermes.cpp Line 623 and deleting "override" makes it compilable now, but more errors appears when I continue to build:
Something seems seriously not right here... Just wondering if it is an issue on my personal laptop or the project or podspec. |
@CyberMew my understanding is that you are trying to build Hermes from trunk with React Native from a branch. That is not guaranteed to work - Hermes and RN are only guaranteed to be source compatible at the same time in their respective trunks. (The following explanation is not necessarily fully accurate, as I am not fully up to speed with the React Native release process, but it should at least give you some idea.) When RN creates a stable branch, they also create a branch in Hermes at the same time, ensuring that the two continue to be source compatible. So, if you want to build Hermes against RN 0.73.x, you need to checkout the Otherwise, you are left in a situation like the current one. RN 0.73.4 and Hermes trunk are incompatible, and nobody has tried to build them together before. It is likely possible, with some amount of effort, to make them work together, but it is impractical for us to provide support for source compilation of all possible version combinations of RN and Hermes. Now, we are well aware that the current situation is not ideal, because it can be difficult, or even practically impossible, to get a newer version of Hermes to work with an older version of React Native. This is very frustrating, especially for the Hermes team, because when we add new features to Hermes, it may take many months before users can try them. We are working on addressing this by introducing the Hermes Stable ABI which will make it possible to drop in any version of Hermes in any future version of React Native. We are close, but we are not 100% there yet. Is there a specific reason you want to compile Hermes from trunk, a new feature that you need? |
Hi, thank you for the information. I am not actually doing it myself, but React Native is the one pulling it from repo during
Doing a search and it seems some others are facing issue with building on iOS as well (though they did not provide actual error but I assume is similar): https://stackoverflow.com/questions/77956730/setting-up-react-native-version-0-73-4-environment-installing-at-ios-for-macos I do not have any issue with RN 0.71.x, since the podspec pulls the tar file from maven. Not sure why it is pulling from source, but I also tried |
@CyberMew it certainly shouldn't be trying to build Hermes from source right out of the box. React Native distributes prebuilt binaries for Hermes that should be used instead. Could you share your exact steps for setting up the project? It may be an issue in React Native instead. |
Uh-oh, at the very least it looks like building Hermes from source using CocoaPods isn't well supported by RN. We need to look into that. |
@neildhar The command I used is Not sure why the env |
My team is experiencing this issue as well. My teammates and I who are located in the US don't have an issue building our React Native project but our deployment system located in Europe and a colleague located there as well have the same |
@Ann-MarieKemp it looks like there are two problems here:
The integration of Hermes with React Native and the associated build process is owned by React Native, so I am transferring this issue to them. |
|
Hi @CyberMew, I think that there is something wrong with your setup. You should never try to use a different version of hermes by tampering with the node_modules and the podspecs because there is no guarantee (yet) that newer versions of Hermes are compatible with older versions of React Native. @Ann-MarieKemp You probably has something somewhere else that is setting a global environment variable On the React Native side, we can disambiguate that |
Summary: In OSS we have reports like [this one](facebook#43241) where env variables from different settings might clash together, making react native apps fail to build hermes. For example, a team might have defined a BUILD_FROM_SOURCE env variable to build their specific project from source and that will clash with how react native apps installs Hermes. This change disambiguate the BUILD_FROM_SOURCE flag we have internally, moving to a less likely to clash RCT_BUILD_HERMES_FROM_SOURCE. ## Changelog: [iOS][Breaking] - Rename BUILD_FROM_SOURCE to RCT_BUILD_HERMES_FROM_SOURCE Differential Revision: D54356337
Summary: In OSS we have reports like [this one](facebook#43241) where env variables from different settings might clash together, making react native apps fail to build hermes. For example, a team might have defined a BUILD_FROM_SOURCE env variable to build their specific project from source and that will clash with how react native apps installs Hermes. This change disambiguate the BUILD_FROM_SOURCE flag we have internally, moving to a less likely to clash RCT_BUILD_HERMES_FROM_SOURCE. ## Changelog: [iOS][Breaking] - Rename BUILD_FROM_SOURCE to RCT_BUILD_HERMES_FROM_SOURCE Reviewed By: huntie Differential Revision: D54356337
Hi @cipolleschi, yes I tried using 0.73.4 with a fresh copy using the standard commands so I don't think it's something to do with my setup (it's a fresh macOS install). No issues when I use my old 0.71.14 project (with Gem/Podfile lock files already working previously). I did not try a fresh copy of 0.71.14 (without the lock files). It seems like there could be some version compatibility? I will delete my 0.71.14 lock files and re-bundle/pod install to see if it is related to Gem/Podfile and report the results. In case it is not clear enough, I did not touch any Hermes code or setting (nor do I want to mess with it!). Everything is default. |
Summary: In OSS we have reports like [this one](#43241) where env variables from different settings might clash together, making react native apps fail to build hermes. For example, a team might have defined a BUILD_FROM_SOURCE env variable to build their specific project from source and that will clash with how react native apps installs Hermes. This change disambiguate the BUILD_FROM_SOURCE flag we have internally, moving to a less likely to clash RCT_BUILD_HERMES_FROM_SOURCE. ## Changelog: [iOS][Breaking] - Rename BUILD_FROM_SOURCE to RCT_BUILD_HERMES_FROM_SOURCE Reviewed By: huntie Differential Revision: D54356337 fbshipit-source-id: 1115e3c22cbcf1d64b7edae30da614d52423123b
@CyberMew, 0.71 didn't have the Can you try to:
You should not see the as you can see from the yellow-ish line, I used 0.73.5, but it should be the same for 0.73.4. |
@cipolleschi I have done that before and Did
Seems like something else is wrong such that it is pulling from main. I am using M1 Pro Sonama 14.3.1 (23D60). Is there something I can edit to force it pulling the artifacts directly and not from main? |
@CyberMew, we have to look into why your system is pulling hermes from main. 🤔
The logic is the following:
I think we are falling into the last case, unfortunately. We need to understand why the check to retrieve the hermes artifacts fails. Can you access this website: What happens if you click here: |
@cipolleschi Thank you for the tip. That was the issue. That url is blocked on my machine and to make things worse I am using Artifactory, so on top of changing the URL I also needed to modify the curl command in the code to add For some reason previously on 0.71.x it will immediately return a download failure with the url during the I think the script should be made more clear to user that the default release artifacts is not accessible (some error code shown), so it is highlighted what happened (i.e. print URL it is grabbing from and also the error code) instead of just defaulting to build source from main "silently" (which is not the usual path). Usually we want to lock the version to use a known compatible version and not use the latest code. Nonetheless thank you very much for your assistance! |
Thank you for your response on this. We tried this but it turned out our issue was the same as @CyberMew's with the blocked url. That fix resolved our issue. |
Yes, I completely agree. We can do a better job when reporting the issue. |
|
Where did you update the command to hit your internal url? I'm also behind an artifactory, can't find the spot to update. |
Access the node_modules/react-native/sdks/hermes-engine/hermes-utils.rb file. You can search for the maven https path entry and curl entries there. Modify them accordingly so it points to your url instead. For the user/pass, just add it after curl commands for the two instances you will find. Hope that helps! |
Hi, is this issue resolved yet? I am experiencing the same problem with the latest React Native version 0.76.2. |
@chirag-blueed this was a local problem on the user's machine. See this message for details: #43241 (comment) |
Bug Description
In Pods: [Hermes] Using the latest commit from main.
Showing Recent Issues
/Users/user/Downloads/AwesomeProject4/node_modules/react-native/ReactCommon/hermes/inspector-modern/InspectorState.cpp:225:40: No member named 'AsyncTrigger' in 'facebook::hermes::debugger::PauseReason'
/Users/user/Downloads/AwesomeProject4/node_modules/react-native/ReactCommon/hermes/inspector-modern/InspectorState.cpp:366:33: No member named 'AsyncTrigger' in 'facebook::hermes::debugger::PauseReason'
Also tried other RN versions #43082
Sidenote: CMAKE is apparently required but it is not part of any dependencies (something to take note of, otherwise the scripts cannot compile at all and error immediately)
Hermes git revision (if applicable):
React Native version: 0.73.4
OS: macOS Sonama 14.3.1
Platform (most likely one of arm64-v8a, armeabi-v7a, x86, x86_64): Apple Silicon
Steps To Reproduce
code example: NA
The Expected Behavior
Compiles successfully.
The text was updated successfully, but these errors were encountered: