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

CLI attempts to launch iOS app despite a build failure, producing misleading error #13839

Closed
shackpank opened this issue May 8, 2017 · 2 comments
Labels
Resolution: Locked This issue was locked by the bot.

Comments

@shackpank
Copy link

Description

The bundle identifier of the application could not be determined.
Ensure that the application's Info.plist contains a value for CFBundleIdentifier.
Print: Entry, ":CFBundleIdentifier", Does Not Exist

Command failed: /usr/libexec/PlistBuddy -c Print:CFBundleIdentifier build/Build/Products/Debug-iphonesimulator/takeoff.app/Info.plist
Print: Entry, ":CFBundleIdentifier", Does Not Exist

This closed issue is similar, and has a wide variety of suggested "fixes". By the looks of things, the root cause of many of them is that the CLI can fail to build the project, but doesn't exit; it goes on to produce the above message by trying to access a file the previous step would have created (had it succeeded). The real error in my case was this, printed just a bit further up:

ld: library not found for -lRNNotifications
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Reproduction Steps and Sample Code

(This is just how I recreated it; the same thing will happen if the app build fails for any other reason)

  1. Find any line in project.pbxproj that references a file in node_modules.
  2. Change the node_modules directory to any directory that doesn't exist.
  3. Delete ios/build
  4. react-native run-ios
  5. The error above appears, with the build failure due to the missing file from node_modules being obscured

Solution

The ChildProcess instance referenced on this line (the commit is master as I write this issue, just in case the line moves) does not have an error property (although it can emit an error event). buildProcess.error is always undefined, and the promise always resolves.

The code argument to the surrounding close event handler function should be used, instead of that property, to decide whether to resolve or reject the promise.

Additional Information

  • React Native version: Observed on 0.42.3
  • Platform: iOS
  • Development Operating System: OS X El Capitan
  • Dev tools: Xcode 8.1
@hramos
Copy link
Contributor

hramos commented Jul 20, 2017

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

  • Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
  • If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
  • Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

@hramos hramos added the Icebox label Jul 20, 2017
@hramos hramos closed this as completed Jul 20, 2017
@hramos
Copy link
Contributor

hramos commented Aug 4, 2017

This is possibly related to #14423. We've now added some logging that might help debug further.

@facebook facebook locked as resolved and limited conversation to collaborators Jul 20, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Jul 20, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests

3 participants