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

x/mobile: enable building frameworks for Catalyst #36856

Open
losh11 opened this issue Jan 29, 2020 · 7 comments · May be fixed by golang/mobile#45
Open

x/mobile: enable building frameworks for Catalyst #36856

losh11 opened this issue Jan 29, 2020 · 7 comments · May be fixed by golang/mobile#45

Comments

@losh11
Copy link

@losh11 losh11 commented Jan 29, 2020

As of macOS 10.15, users can build iPad apps to run on macOS using Catalyst. However if you build a framework using gomobile, even though the framework has support for x86_64, Xcode will display an error.

To fix this, all you need to do is target clang for the macOS sdk & add a cflag with -target x86_64-apple-ios13.0-macabi. Fully tested example below.

Gomobile should support specifying a target catalyst. In x/mobile/cmd/gomobile/env.go, add a new case "catalyst" for function envInit which looks like this:

case "catalyst":
    clang, cflags, err = envClang('macosx')
    cflags += " -target x86_64-apple-ios13.0-macabi"
@gopherbot gopherbot added this to the Unreleased milestone Jan 29, 2020
@gopherbot gopherbot added the mobile label Jan 29, 2020
@hyangah hyangah added the help wanted label Jan 30, 2020
@losh11
Copy link
Author

@losh11 losh11 commented Feb 1, 2020

@hyangah if y'all are okay with this, I can implement?

@agnivade
Copy link
Contributor

@agnivade agnivade commented Feb 2, 2020

All yours !

@damiandizeo
Copy link

@damiandizeo damiandizeo commented Mar 24, 2020

@losh11 added a new case "catalyst" for function envInit , but when I do 'gomobile bind' and create the .framework, Xcode still displaying error in when building on macOS Catalyst. Am I missing something ?

@losh11
Copy link
Author

@losh11 losh11 commented Mar 24, 2020

@damiandizeo I'm not able to check exactly what you've done without a full set of diffs. This likely means your framework is not build for x86_64h as required by catalyst.

@damiandizeo
Copy link

@damiandizeo damiandizeo commented Mar 24, 2020

@losh11 thanks, adding the cflag '-target x86_64-apple-ios13.0-macabi', was able to compile the framework and now runs under Mac Catalyst

@losh11
Copy link
Author

@losh11 losh11 commented Mar 25, 2020

Great to hear @damiandizeo, if you or anyone else has time to implement this, that would be awesome. Unfortunately I no longer have the time to do this myself.

dpwiese added a commit to dpwiese/mobile that referenced this issue Apr 1, 2020
See: golang/go#36856

As of macOS 10.15 target catalyst can be used to build an iPad app to run on macOS. Existing .Framework built with gomobile produces the following error when targetting catalyst:

```
error: Building for Mac Catalyst, but the linked framework 'Sample.framework' was built for iOS + iOS Simulator. You may need to restrict the platforms for which this framework should be linked in the target editor, or replace it with an XCFramework that supports both platforms. (in target 'MySampleApp' from project 'MySampleApp')
```

This commit adds a case for catalyst (although architecture is just amd64) when configuring the environment for each architecture, providing the flags needed to enable the built .Framework to be used with catalyst.
@dpwiese dpwiese linked a pull request that will close this issue Apr 1, 2020
@dpwiese
Copy link

@dpwiese dpwiese commented Apr 1, 2020

I looked at this quickly last night, and had a bit of trouble coming up with a solution as elegant as I had hoped. The environment is configured in envInit() for each architecture in allArchs. Support for catalyst needs to provide an additional configuring, but for the existing amd64 architecture. I don't think it makes sense to add catalyst to allArchs as a new architecture, as it is not. Treating it as such seems like a poor choice, and furthermore would require many changes throughout to support it if added as a new "architecture".

Rather, when setting up the environment in envInit() I've simply included it as an additional case alongside the existing true architectures. I've opened a (draft) PR with the current proposed solution here: golang/mobile#45

Feedback is appreciated, after which I'll mark ready for review. 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

7 participants
You can’t perform that action at this time.