I ran this command: brew install go --*HEAD*
Now Xcode compiles without an error and ENABLE_BITCODE=YES On Tuesday, May 14, 2019 at 9:18:12 PM UTC-7, Tristian Azuara wrote: > > Hi!, > > gomobile does not produce BITCODE enabled frameworks, (AFAIK) you have to > set the XCode `ENABLE_BITCODE` build setting to `NO`, `gomobile` (the > latest version) automatically adds the `-fembed-bitcode` as C flag, here > you can find a better explanation of it: > > * https://stackoverflow.com/a/34965178 > > On Tuesday, May 14, 2019 at 9:00:32 PM UTC-7, const...@topinvestor.app > wrote: >> >> When I compile with: >> gomobile bind -target=ios -tags="ios" -v mygomobileios >> >> >> and importing the generated Mygomobileios.framework >> >> I get an error: >> >> ld: >> '/mygo/src/mygomobileios/gomobileios_test/Mygomobileios.framework/Mygomobileios(go.o)' >> >> does not contain bitcode. You must rebuild it with bitcode enabled (Xcode >> setting ENABLE_BITCODE), obtain an updated library from the vendor, or >> disable bitcode for this target. for architecture arm64 >> >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> Which indicates the generated framework does not contain bitcode. >> >> Ho to get the bitcode generated? >> >> On Monday, April 1, 2019 at 9:30:23 AM UTC-7, Tristian Azuara wrote: >>> >>> Hi Elias, thank you for the quick reply, I see, you're correct it does >>> support the archs for ios, I had not tried it for ios, because the >>> documentation just mentions that you can specify specific instruction sets >>> when binding for android: >>> >>> $ gomobile bind --help >>> >>> >>> By default, -target=android builds shared libraries for all supported >>>> >>>> instruction sets (arm, arm64, 386, amd64). A subset of instruction sets >>>> >>>> can be selected by specifying target type with the architecture name. >>>>> E.g., >>>> >>>> -target=android/arm,android/386. >>>> >>>> >>>>> For -target ios, gomobile must be run on an OS X machine with Xcode >>>> >>>> installed. The generated Objective-C types can be prefixed with the >>>>> -prefix >>>> >>>> flag. >>>> >>>> >>> There's no mention that you can filter out instruction sets for iOS but >>> I just tested using it and it works!, thank you for pointing that out. >>> >>> Now, regarding the bitcode part basically, because it's added >>> automatically; any libraries that don't have BITCODE enabled don't link >>> properly, here's some sample output: >>> >>> GO111MODULE=off gomobile bind -v -target=ios/arm,ios/arm64,ios/amd64 >>> -tags=ios example.com/mobile >>> runtime/cgo >>> golang.org/x/mobile/internal/mobileinit >>> os/user >>> net >>> example.com/pycore >>> example.com/jscore >>> # example.com/pycore >>> ld: warning: ignoring file pycore/libpython-scriptengine.a, file was >>> built for archive which is not the architecture being linked (armv7): >>> pycore/libpython-scriptengine.a >>> ld: warning: object file (/Users/tristian/go/src/ >>> example.com/pycore/libpython-scriptengine-ios.a(python-scriptengine-ios.o)) >>> was built for newer iOS version (9.3) than being linked (7.0) >>> ld: '/Users/tristian/go/src/ >>> example.com/pycore/libpython-scriptengine-ios.a(python-scriptengine-ios.o)' >>> does not contain bitcode. You must rebuild it with bitcode enabled (Xcode >>> setting ENABLE_BITCODE), obtain an updated library from the vendor, or >>> disable bitcode for this target. for architecture armv7 >>> clang: error: linker command failed with exit code 1 (use -v to see >>> invocation) >>> # example.com/jscore >>> ld: warning: ignoring file jscore/libscriptengine-ios-x86_64.a, file was >>> built for archive which is not the architecture being linked (armv7): >>> jscore/libscriptengine-ios-x86_64.a >>> ld: warning: object file (/Users/tristian/go/src/ >>> example.com/jscore/libscriptengine-ios-arm.a(test_lib_for_ios.o)) was >>> built for newer iOS version (10.2) than being linked (7.0) >>> ld: '/Users/tristian/go/src/ >>> example.com/jscore/libscriptengine-ios-arm.a(test_lib_for_ios.o)' does >>> not contain bitcode. You must rebuild it with bitcode enabled (Xcode >>> setting ENABLE_BITCODE), obtain an updated library from the vendor, or >>> disable bitcode for this target. for architecture armv7 >>> clang: error: linker command failed with exit code 1 (use -v to see >>> invocation) >>> gomobile: darwin-arm: go build -tags ios ios -v -buildmode=c-archive -o >>> /var/folders/g1/v3hz1sm92nv7wbzpg3dx_h_h0000gp/T/gomobile-work-974051835/mobile-arm.a >>> >>> gobind failed: exit status 2 >>> >>> make: *** [Mobile.framework] Error 1 >>> >>> This would force us to recompile libpython-scriptengine-ios.a or any >>> other libraries that don't have bitcode support >>> >>> When I comment out -fembed-bitcode I no longer see that error. >>> >>> Best, Tristian >>> >>> On Monday, April 1, 2019 at 12:09:35 AM UTC-7, ma...@eliasnaur.com >>> wrote: >>>> >>>> Hi, >>>> >>>> The -target flag does support architectures. Have you tried -target >>>> ios/amd64,ios/arm64,ios/arm from your example? >>>> >>>> I'm not sure I understand the problem with bitcode and macOS; what is >>>> the error you get from -fembed-bitcode? >>>> >>>> - elias >>>> >>>> On Monday, April 1, 2019 at 6:32:35 AM UTC+2, Tristian Azuara wrote: >>>>> >>>>> Hi! >>>>> >>>>> First, gomobile has been a real life saver thank you to all of those >>>>> who have contributed. >>>>> >>>>> The current commit at master >>>>> (167ebed0ec6dd457a6b24a4f61db913f0af11f70) automatically adds the >>>>> "-fembed-bitcode" flag to the cflags and >>>>> it also automatically builds for all of iOS architectures. >>>>> >>>>> We currently use `gomobile` to produce a framework for iOS and macOS >>>>> applications. We also include applications for macOS that do not include >>>>> support for instruction sets such as `386` but iOS does, some of those >>>>> libraries we have no control over and some are our own. >>>>> >>>>> Our current workaround is for us to manually patch `gomobile`'s >>>>> source, like follows: >>>>> >>>>> λ ~/go/src/golang.org/x/mobile (master): git diff -p >>>>> diff --git a/cmd/gomobile/env.go b/cmd/gomobile/env.go >>>>> index dbf9c8c..8f21b10 100644 >>>>> --- a/cmd/gomobile/env.go >>>>> +++ b/cmd/gomobile/env.go >>>>> @@ -23,7 +23,8 @@ var ( >>>>> androidArmNM string >>>>> darwinArmNM string >>>>> >>>>> - allArchs = []string{"arm", "arm64", "386", "amd64"} >>>>> + // allArchs = []string{"arm", "arm64", "386", "amd64"} >>>>> + allArchs = []string{"arm", "arm64", "amd64"} >>>>> ) >>>>> >>>>> func buildEnvInit() (cleanup func(), err error) { >>>>> @@ -137,7 +138,7 @@ func envInit() (err error) { >>>>> default: >>>>> panic(fmt.Errorf("unknown GOARCH: %q", arch)) >>>>> } >>>>> - cflags += " -fembed-bitcode" >>>>> + // cflags += " -fembed-bitcode" >>>>> if err != nil { >>>>> return err >>>>> } >>>>> >>>>> I think that the addition of the following options would greatly >>>>> simplify our CI/CD process, the goal would be to be able to use the >>>>> command >>>>> as follows: >>>>> >>>>> $ gomobile bind -target=ios/arm,ios/arm64,ios/amd64 -nobitcode >>>>> example.com/libs/mobile >>>>> >>>>> By running it that way basically one would be able to exclude iOS >>>>> simulator arch and the bitcode situation. I understand that probably it >>>>> may >>>>> not be something common, but being able to adjust the build process would >>>>> be a great boon. >>>>> >>>>> Does anyone else find that this would be something useful?, I'd be >>>>> happy to contribute to this. >>>>> >>>>> Cheers, Tristian. >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e470a8da-f27c-49e5-abfc-66144bec06ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
