Exporting to iOS project failed to build

[shunia]

trafficstars

Environment

How do you use Sentry? Sentry SaaS (sentry.io) or self-hosted/on-premise (which version?)

SaaS

Which version of the SDK?

0.19.0

How did you install the package? (Git-URL, Assetstore)

Git-URL

Which version of Unity?

2021.1.25f1

Is this happening in Unity (editor) or on a player like Android, iOS, Windows?

Error only occurs in iOS project, we can not build the exported project, if remove Sentry, everything works fine; Unity editor works as expected, exported Android Project works too. We are not aiming for other platforms.

Steps to Reproduce

1. Setup Sentry followed by documentation;
2. Export iOS project to an existing iOS project (replace);
3. Build the iOS project in xCode as usual;

Expected Result

Build pass and everything works.

Actual Result

Failed when build iOS project:

ld: warning: object file (/Users/Clover/Desktop/_/ios_exported/Libraries/lib_burst_generated.a(lib_burst_generated_part_0_merged.o)) was built for newer iOS version (15.2) than being linked (11.0)
ld: warning: object file (/Users/Clover/Desktop/_/ios_exported/Libraries/lib_burst_generated.a(lib_burst_generated_part_4.o)) was built for newer iOS version (15.2) than being linked (11.0)
ld: warning: object file (/Users/Clover/Desktop/_/ios_exported/Libraries/lib_burst_generated.a(lib_burst_generated_part_1.o)) was built for newer iOS version (15.2) than being linked (11.0)
ld: warning: object file (/Users/Clover/Desktop/_/ios_exported/Libraries/lib_burst_generated.a(lib_burst_generated_part_3.o)) was built for newer iOS version (15.2) than being linked (11.0)
ld: warning: object file (/Users/Clover/Desktop/_/ios_exported/Libraries/lib_burst_generated.a(lib_burst_generated_part_2.o)) was built for newer iOS version (15.2) than being linked (11.0)
ld: warning: object file (/Users/Clover/Desktop/_/ios_exported/Libraries/lib_burst_generated.a(lib_burst_generated_part_0.o)) was built for newer iOS version (15.2) than being linked (11.0)
Undefined symbols for architecture arm64:
  "__NSNumberOrNil", referenced from:
      ___SentryNativeBridgeWriteScope_block_invoke in SentryNativeBridge.o
  "__NSBoolOrNil", referenced from:
      ___SentryNativeBridgeWriteScope_block_invoke in SentryNativeBridge.o
  "__NSStringOrNil", referenced from:
      ___SentryNativeBridgeWriteScope_block_invoke in SentryNativeBridge.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[bitsandfoxes]

Hey @shunia, thanks for raising this. I tried reproducing the issue with the versions you provided but had no luck. Even with the Burst package installed. Could you provide us with a small repro so we can take a look?

[shunia]

It could be really hard to provide a minimal repro for you guys to look for, but I will try my best.

And btw my exported project is used as a library or a part of the real iOS project, is it possible that the exported project is conflicted with the original iOS project?

[bitsandfoxes]

Unfortunately, this is a use case we don't really support. But it could explain the issue: The SDK manipulates the generated Xcode project and copies that SentryNativeBridge over, to make it all work.

[bitsandfoxes]

Could you try to disable Tools -> Sentry -> Advanced -> iOS Native Support and then build again? This should leave you with only the C# layer.

[shunia]

Unfortunately, this is a use case we don't really support. But it could explain the issue: The SDK manipulates the generated Xcode project and copies that SentryNativeBridge over, to make it all work.

Yes it does, we just can not understand why it would cause compile time error(We are not so familiar with iOS codes though).

Could you try to disable Tools -> Sentry -> Advanced -> iOS Native Support and then build again? This should leave you with only the C# layer.

This will shutdown the objective-c error catching functionality right? We will definitely try this, and I will be back with the result. Thank you for your help!

[bitsandfoxes]

Yes it does, we just can not understand why it would cause compile time error(We are not so familiar with iOS codes though).

The SentryNativeBridge.m is an additional file that the SDK copies from Unity to the generated Xcode project, allowing the C# layer to communicate with the Cocoa SDK. From your log, it looks like it can't find it.

This will shutdown the objective-c error catching functionality right?

Yes. I guess the surrounding iOS app brings its own Sentry setup?

[shunia]

Sorry it's been a while, we are busy getting stuff done. And it's time we go back to sort out how to integrate Sentry into our existing iOS code base.

Yes. I guess the surrounding iOS app brings its own Sentry setup?

No, never. The iOS project haven't implemented Sentry.

And we have made a little bit change to the file SentryNativeBridge.m to make it pass the compilation:

But it's annoying to have to modify the file after exporting iOS project, how can we make this modification consistent when exporting project?

[shunia]

Could you try to disable Tools -> Sentry -> Advanced -> iOS Native Support and then build again? This should leave you with only the C# layer.

This is not working. The error is caused by SentryNativeBridge.m, and disabling iOS Native Support will not change this file.

[bitsandfoxes]

how can we make this modification consistent when exporting project?

Unfortunately, short of compiling the SDK yourself, there are currently no hooks to consistently change the file.

This is not working. The error is caused by SentryNativeBridge.m, and disabling iOS Native Support will not change this file.

You would have to do a clean build with the iOS native support disabled so the bridge file does not get copied over to the Xcode project.

[shunia]

You would have to do a clean build with the iOS native support disabled so the bridge file does not get copied over to the Xcode project.

Oops, if 'clean build' means that we have to clean the project cache - which is the Library folder I believe - it's so time consuming and we might have to try this later.

Now we just manually try not to override the file. At least it works.

And huge thanks for your help! We have made the integration done, for both of our mobile platforms. And I will leave the issue for you guys to decide to close or not.

[bitsandfoxes]

My bad, with clean build I mean to replace when exporting the Xcode project and not to append. The SDK can't remove files that are already there.

And we have made a little bit change to the file SentryNativeBridge.m to make it pass the compilation:

I brought this up with the team and without more logs/context our best guess would be that it has something to do with the inline settings of the surrounding app?

We have made the integration done, for both of our mobile platforms.

That's awesome! Happy to hear! Are you embedding the game inside of an Android app as well?

[shunia]

clean build I mean to replace when exporting the Xcode project and not to append

Well, we are now using a BuildPlayer script to export our project, and now it just export that file every time, and if target iOS there's no way to choose replace or append but we believe it's using append mode to export. I will try this by using Export from the Build Settings menu of course, but we might not be able to use this method for release now...

That's awesome! Happy to hear! Are you embedding the game inside of an Android app as well?

Thank you. And yes, we are working on a Unity project(a game) for Android and iOS platform. We export the Unity project to Android and iOS project, and run the UnityPlayer inside our existing Android/iOS native app.

[jzapdot]

We are experiencing this same error.

Environment

How do you use Sentry?

Sentry SaaS (sentry.io)

Which version of the SDK?

Updating from v0.15.0 to v0.22.1.

How did you install the package? (Git-URL, Assetstore)

Git-URL

Which version of Unity?

v2021.3.1f1

Is this happening in Unity (editor) or on a player like Android, iOS, Windows?

When building to iOS.

Steps to Reproduce

This is our Sentry config.

In code we have il2cpp line numbers enabled.

1. Clean build folder
2. Build to iOS via BuildPlayer API with development build and allow debugging options set.
3. Attempt to build to device.

Expected Result

What you thought would happen.

App is built and run on device without errors.

Actual Result

What actually happened. Maybe a screenshot/recording? Maybe some logs?

App fails to compile due to Sentry code.

Any logs or screenshots

Undefined symbols for architecture arm64:
  "__NSNumberOrNil", referenced from:
      ___SentryNativeBridgeWriteScope_block_invoke in SentryNativeBridge.o
  "__NSBoolOrNil", referenced from:
      ___SentryNativeBridgeWriteScope_block_invoke in SentryNativeBridge.o
  "__NSStringOrNil", referenced from:
      ___SentryNativeBridgeWriteScope_block_invoke in SentryNativeBridge.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[marvinmarnold]

I am also seeing this on Unity 2020.3.30f1 and Sentry 0.22.1.

[bitsandfoxes]

Thanks for the reports. I'm looking into it.

[bitsandfoxes]

I can reproduce the issue locally and the workaround @shunia was demonstrating seems to be the fix. I'm just not sure why this is an issue in the first place and what option controls this behaviour. I assume it's an option since this does not seem to be an issue in non-debug builds.

[shunia]

Although the problem has been fixed(I haven't validated myself), I want to mention that

1. Sentry is not capturing any error messages for my production release, with my use case of:
   • Exporting Unity project into an Android project and then build the Android project into an AAR, then use this AAR inside a full functional Android project;
   • Exporting Unity project into an iOS project and then link it as an iOS library inside a full functional iOS project;
2. It increase ~2-3 mb final app size;

For these two reasons we sadly have removed Sentry from our project for now. And we have tried the Unity Cloud Diagnostics too it's not working either. For anyone catches this information, I believe you can try to resolve this problem but we have gave up due to project timeline.

[bitsandfoxes]

Sorry to see you running into those issues. Did you happen to have any logs Sentry might have generated in the final app?

[jzapdot]

I can reproduce the issue locally and the workaround @shunia was demonstrating seems to be the fix. I'm just not sure why this is an issue in the first place and what option controls this behaviour. I assume it's an option since this does not seem to be an issue in non-debug builds.

I don't understand how this is considered completed. It's a blocker for us to be able to take this update on our project. The solution proposed here seems more of a workaround for a developer to hand edit Sentry's il2cpp generated code and ultimately may not work.

[bitsandfoxes]

I don't understand how this is considered completed. It's a blocker for us to be able to take this update on our project. The solution proposed here seems more of a workaround for a developer to hand edit Sentry's il2cpp generated code and ultimately may not work.

I fumbled my communication here a bit. I originally assumed that this issue was related to the Unity project being embedded within an iOS app. But based on your additional information I could reproduce the issue and we merged a PR containing the fix in https://github.com/getsentry/sentry-unity/pull/932. It will be part of the next release.

[shunia]

Sorry to see you running into those issues. Did you happen to have any logs Sentry might have generated in the final app?

Just simply none LOL.

[bitsandfoxes]

None at all? Not even the C# layer trying to initialize itself? At the very least C# should have done something.

[jzapdot]

Excellent, thanks for the clarification! Looking forward to it.

[shunia]

None at all? Not even the C# layer trying to initialize itself? At the very least C# should have done something.

Ah, of course. I mean there's no Sentry related log except that I tried to modify Sentry options and logged the option details. Which means Sentry itself at C# layer is working, but for some reason there's nothing being captured in production builds. I'm not really sure what happened, and our native app engineers are too busy to help me sorting this problem out, so we just have to remove Sentry for now.