search

react-native-community / releases

React Native releases
https://github.com/facebook/react-native/
1.5k stars 404 forks source link

`run-ios` in release configuration #249

Closed lunaleaps closed 3 years ago

lunaleaps commented 3 years ago

There are a couple of issues with npx react-native run-ios --configuration 'Release'

1. index.js does not exist

@mikehardy has reported an error with 

npx react-native init TestProject66 --version 0.66.0-rc.0
cd TestProject66
npx react-native run-ios --configuration 'Release'

and getting error: 

❌  error: Entry file index.js does not exist. If you use another file as your entry point, pass ENTRY_FILE=myindex.js

2. thread-local storage is not supported for the current target

@lunaleaps has issue with Xcode 12.5 for both 0.65.1 and 0.66.0-rc.0 when running:

npx react-native init TestProject [--version 0.66.0-rc.0]
cd TestProject
npx react-native run-ios --configuration 'Release'

and getting the error: 

warning: Capabilities for Signing & Capabilities may not function correctly because its entitlements use a placeholder team ID. To resolve this, select a development team in the MyTestProject66 editor. (in target 'MyTestProject66' from project 'MyTestProject66')
/Users/luwe/MyTestProject66/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.5.99. (in target 'YogaKit' from project 'Pods')
/Users/luwe/MyTestProject66/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.5.99. (in target 'Flipper-Glog' from project 'Pods')

The following build commands failed:
    CompileC /Users/luwe/Library/Developer/Xcode/DerivedData/MyTestProject66-efwtfjnninejtqfidwsnxehgajhj/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/RCT-Folly.build/Objects-normal/i386/F14Table.o /Users/luwe/MyTestProject66/ios/Pods/RCT-Folly/folly/container/detail/F14Table.cpp normal i386 c++ com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)

This seems like a known issue and has some discussion here: https://github.com/facebook/react-native/issues/31480#issuecomment-897733307

@lunaleaps has tried following @MikeHardy's suggestions by adding this to Podfile: https://github.com/facebook/react-native/issues/31480#issuecomment-902912841 but hasn't worked.

lunaleaps commented 3 years ago

Action Items:

mikehardy commented 3 years ago

I'm surprised the post install doesn't work, it must not have been applied correctly, if it really moved deployment target up, then the symbol exists and f14table compiles this is a rare 'really really does work around it' 100% certainty workaround. That sad, still needs a real fix 😁

mikehardy commented 3 years ago

Xcode 13 only works with same workarounds, I've tested. Also needs the swift hack I think, to set library path

fkgozali commented 3 years ago

@mikehardy I did a clean try on Xcode 12.5. With your post_install workaround, I was able to successfully build the Release flavor. I couldn't repro the index.js issue though

The post_install hack: https://github.com/facebook/react-native/issues/31480#issuecomment-902912841

fkgozali commented 3 years ago

I couldn't repro the index.js issue though

oops, looks like I accidentally had an unrelated index.js in a parent dir, so that "avoided" the problem but incorrectly. The issue is this line is looking for index.js at the wrong directory level...:

https://github.com/facebook/react-native/blob/main/scripts/react-native-xcode.sh#L77

We'll fix forward and pick to 0.66 RC

lunaleaps commented 3 years ago

@mikehardy Yup as Kevin mentioned we were able to repro your issue and found the cause to be changes in https://github.com/facebook/react-native/pull/29263

Additionally, I got around the thread-local storage is not supported for the current target error with your "dance" post_install hook. I just didn't realize I needed to run pod install after updating the Podfile. I thought npx react-native run-ios.. would run it..whoops!

Thanks for all your help!

lunaleaps commented 3 years ago

But as a side-note.. we should figure out how to not have to do this "dance".. I'm not exactly sure what that would be.. but on my radar

mikehardy commented 3 years ago

I also would really love to avoid the intricate post-install hackery but:

a) I am happy that I'm not crazy / I'm generating reproducible reports at all. I mean, that's like 90% of the job and it's quite frustrating at times! b) I am really happy that you were able to see the full requirement of post-install hackery needed, and also see that when you put it all together, it really does work, see a) about reproduction :-) b) I am really really happy that you were able to find the release mode issue - since that's the only issue I saw, makes me excited to see 0.66 wind its way to release

Cheers!

fkgozali commented 3 years ago

@mikehardy - any concern if we include your post_install workaround in the app template for 0.66 for now? Yes it's not ideal, but it would unblock many ppl atm.

mikehardy commented 3 years ago

None at all - I've been using it personally and hearing success feedback on it for all the major configs (M1 or intel, hermes or no) so it should improve dev experience, and worst case it's just the template, people can rip it out

mikehardy commented 3 years ago

(although that said, no good deed will be unpunished, I'm sure we'll discover some new corner cases if/when it goes in - still, incremental improvement...)

fkgozali commented 3 years ago

Yeah understood, we're just trying to buy some time atm :). I'll add your workaround with a big warning

fkgozali commented 3 years ago

Alright, ENTRY_FILE fix: https://github.com/facebook/react-native/commit/945c5f714d9b3a75f0be02b3a408f865c9021aa7 And post_install recipe: https://github.com/facebook/react-native/commit/ac4ddec542febda744de218dae3a3d34edc7da84

fkgozali commented 3 years ago

Keeping this open until commits are picked and in case you wanna verify @mikehardy

mikehardy commented 3 years ago

Hey @fkgozali i checked and the commit listed as fixing m1 builds does not work

https://github.com/facebook/react-native/commit/eb938863063f5535735af2be4e706f70647e5b90

That might fix xcode 13 on Intel, but m1 requires swift libs first not last. Of course that seems strange but it's a real thing, I tested both variations, only swift first builds on m1 in my experience. Unexpected result but that's what I saw, and there's positive results with it on the Apple m1 issue.

Discussion visible on ios discord channel

fkgozali commented 3 years ago

That might fix xcode 13 on Intel, but m1 requires swift libs first not last.

Yeah I saw your discussion with @sammy-SC. In fact, a commit is landing as of now to switch that order in app template and RNTester. So with those picked to RC 0.66, hopefully that's all we need :)

mikehardy commented 3 years ago

Fantastic! Then yes - with that order being swift-first and the Folly "dance" (ios version bump + avoiding redefining time symbol) everything on Apple machines should be happy :crossed_fingers:

fkgozali commented 3 years ago

Alright, here's the commit: https://github.com/facebook/react-native/commit/329b026f3a48a4228a89696540ba459276f9a2c2 -- will request pick

lunaleaps commented 3 years ago

Closing as this is now fixed in 0.66.0-rc.2