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

Problem with third-party in Xcode 10 building to iOS physical device #19839

Closed
3 tasks done
dlimx opened this issue Jun 21, 2018 · 20 comments
Closed
3 tasks done

Problem with third-party in Xcode 10 building to iOS physical device #19839

dlimx opened this issue Jun 21, 2018 · 20 comments
Labels
Platform: iOS iOS applications. Resolution: Locked This issue was locked by the bot.

Comments

@dlimx
Copy link

dlimx commented Jun 21, 2018

Environment:

Environment:
  OS:  macOS 10.14
  Node:  8.11.2
  Yarn:  1.7.0
  npm:  5.6.0
  Watchman:  4.7.0
  Xcode:  Xcode 10.0 Build version 10L176w
  Android Studio:  2.3 AI-162.4069837

Packages: (wanted => installed)
  react: 16.3.1 => 16.3.1
  react-native: 0.55.4 => 0.55.4

__

Description

third-party encounters a semantic issue during Xcode builds to physical iOS device. The error is No member named '__rip' in '__darwin_arm_thread_state64'

Reproducible Demo

On macOS Mojave with Xcode 10.

react-native init Test
cd Test
yarn start
Xcode build to device

Fails due to No member named '__rip' in '__darwin_arm_thread_state64'

@react-native-bot react-native-bot added the Platform: iOS iOS applications. label Jun 21, 2018
@hramos
Copy link
Contributor

hramos commented Jun 22, 2018

Can you try using the latest 0.56 RC? That release contains some related fixes and we'd like to ensure the issue you're describing is not something that is already fixed.

@dlimx
Copy link
Author

dlimx commented Jun 22, 2018

I've applied manual fixes for libfishook.a and glog-0.3.4 - it builds fine to non-device simulators. I'll definitely confirm tomorrow though if it's something that's already been fixed.

@jumarmartin
Copy link

jumarmartin commented Jun 22, 2018

Not @dlimx, but can report the same. Using the latest (-1) RC.

Current Environment: 
macOS: 10.14 build 18A314h
node: 9.4.0
yarn: 1.7.0
npm: 6.1.0
watchman: 4.9.0
Xcode: 10.0 build 10L177m
Android Studio: Build #AI-173.4670197

react: 16.3.2
react-native-cli: 2.0.1
react-native: 0.56.0-rc.2

This error also occurs when building for a "Generic iOS Device"
The error seem to stem from signalhandler.cc in the glog folder, on line 78
return (void*)context->PC_FROM_UCONTEXT;

I saw that there was a version bump to rc.3, I couldn't use react-native-git-upgrade nor react-native upgrade to upgrade to that version.

@tanabs18
Copy link

tanabs18 commented Jun 29, 2018

@hramos In response to your question^^, I'm using the same environment as OP and having the same issue on rc.2, rc.3, and rc.4

@PrimeObjects

This comment has been minimized.

@JoseVf
Copy link

JoseVf commented Jul 26, 2018

It happens to me on a recently created RN project, but I'm using xCode 9.4
IDEs:
Xcode: 9.4.1/9F2000 - /usr/bin/xcodebuild
npmPackages:
react: 16.4.1 => 16.4.1
react-native: 0.56.0 => 0.56.0

@mattijsf
Copy link
Contributor

I got error as well after updating to Xcode 10. Build goes fine for simulators but not for Generic / Physical Devices. This is blocking development using Xcode 10 atm :( Which wouldn't be a problem if we could use Xcode 9.4. But that means we cannot develop with iOS 12.

Environment:
  OS: macOS High Sierra 10.13.6
  Node: 8.3.0
  Yarn: 1.3.2
  npm: 6.4.1
  Watchman: 4.9.0
  Xcode: Xcode 10.0 Build version 10A255
  Android Studio: 3.1 AI-173.4907809

Packages: (wanted => installed)
  react: ^16.3.1 => 16.3.1
  react-native: ^0.55.4 => 0.55.4

@kelset
Copy link
Contributor

kelset commented Sep 18, 2018

@mattijsf have you tried with 0.57? As you can see on #19573, we are not fully XCode 10 ready, and any help in fixing the remaining issues is surely welcome.

@mattijsf
Copy link
Contributor

mattijsf commented Sep 18, 2018

I haven't. I can try but I don't expect this will make a difference. I think this has something to do with the glog library:

During the build / configure step of that library it outputs the follow:

cd node_modules/react-native/third-party/glog-0.3.4/ && ./configure

...
checking for sys/ucontext.h... yes
checking how to access the program counter from a struct ucontext... uc_mcontext->__ss.__rip
checking that generated files are newer than configure... done
...

Looking at the relevant script it seems that they do some one-off trial 'n error for obtaining this "program counter":
https://github.com/google/glog/blob/v0.3.4/m4/pc_from_ucontext.m4#L16-L54
Once it finds a working field it writes it to node_modules/react-native/third-party/glog-0.3.4/src/config.h:

...
#define PC_FROM_UCONTEXT uc_mcontext->__ss.__rip
...

Which in turn only works for simulators (which is the same architecture as macOS: darwin/x86) but no longer for devices (darwin/arm)

@mattijsf
Copy link
Contributor

mattijsf commented Sep 18, 2018

I found a workaround but its untested:
It involves manually editing node_modules/react-native/third-party/glog-0.3.4/src/config.h:

Replace:

/* How to access the PC from a struct ucontext */
#define PC_FROM_UCONTEXT uc_mcontext->__ss.__rip

With:

/* How to access the PC from a struct ucontext */
#if defined(__arm__) || defined(__arm64__)
#define PC_FROM_UCONTEXT uc_mcontext->__ss.__pc
#else
#define PC_FROM_UCONTEXT uc_mcontext->__ss.__rip
#endif

Using this it will compile for both targets. My knowledge is pretty much absent regarding the use of these values. Except that __darwin_arm_thread_state64 does provide the information that this pointer is in fact the "program counter":
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/mach/arm/_structs.h @ line 140:

_STRUCT_ARM_THREAD_STATE64
{
	__uint64_t    __x[29];	/* General purpose registers x0-x28 */
	__uint64_t    __fp;		/* Frame pointer x29 */
	__uint64_t    __lr;		/* Link register x30 */
	__uint64_t    __sp;		/* Stack pointer x31 */
	__uint64_t    __pc;		/* Program counter */
	__uint32_t    __cpsr;	/* Current program status register */
	__uint32_t    __pad;    /* Same size for 32-bit or 64-bit clients */
};

@kelset
Copy link
Contributor

kelset commented Sep 18, 2018

Well in 0.57 we use glog 0.3.5, maybe that script is fixed there?

@mattijsf
Copy link
Contributor

@kelset I missed that part. I give it a try!

@mattijsf
Copy link
Contributor

I updated to 0.57.0 and did a full clean using:

rm -rf node_modules
npm cache clear --force ; watchman watch-del-all ; rm -rf $TMPDIR/react-* ; rm -rf ~/.rncache

But the error remains the same. The above workaround still seems to work though.

@mattijsf
Copy link
Contributor

mattijsf commented Sep 18, 2018

The problems seems to be resolved now. I'm not entirely sure but I think it had to do with the way I was installing glog.

With earlier iterations (both Xcode / RN) I was running the glog ./configure script manually due to Xcode failing to do it properly.

But that actually produces a config.h that breaks on Xcode 10. The following react-native script is actually required for getting the correct config.h for Xcode 10:
https://github.com/facebook/react-native/blob/v0.57.0/scripts/ios-configure-glog.sh#L44-L51
That will build glog with ./configure --host arm-apple-darwin and taking into account patching the PC_FROM_UCONTEXT macro.

I learned that Xcode 10 failed building / installing the third-party dependencies only at the first build and that subsequent builds actually takes care of installing glog correctly: #21168 (comment)

@Monte9

This comment has been minimized.

@MayeuldP

This comment has been minimized.

@Monte9

This comment has been minimized.

@yllow

This comment has been minimized.

@Monte9

This comment has been minimized.

@hramos hramos added this to the 0.58 RC milestone Sep 25, 2018
@hramos
Copy link
Contributor

hramos commented Sep 25, 2018

The original issue appears to be resolved in 0.57. For anything else related to third party dependencies, the issue you're looking for is #20774.

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

No branches or pull requests