gomobile does not work in module mode. See #27234

@AlexRouSg Thank you for the reply yes and thank you for the link!, I was aware of this limitation, however this issue is slightly different, in the issue that you mention the build is done with GO111MODULE=on (and seemingly outside a GOPATH) as it can be seen from the command output:

gomobile: go build -buildmode=c-shared -o=/var/folders/nt/0hzfppd92jvbk99fhvnhy8ph0000gn/T/gomobile-work-327189385/android/src/main/jniLibs/armeabi-v7a/libgojni.so gobind failed: exit status 1
go: finding github.com/dustin/go-humanize v0.0.0-20180713052910-9f541cc9db5d
go: finding golang.org/x/mobile v0.0.0-20180808221059-bceb7ef27cc6
can't load package: package gobind: unknown import path "gobind": cannot find module providing package gobind

(notice the go: finding ... statements, those indicate that the module system is being used)

In this issue the the build is done inside a GOPATH and with GO111MODULE=off, I was under the impression that the rules defined here would take effect:

• "Additional Details – "Minimal Module Compatibility": https://github.com/golang/go/wiki/Modules#how-are-v2-modules-treated-in-a-build-if-modules-support-is-not-enabled-how-does-minimal-module-compatibility-work-in-197-1103-and-111

The type-checking package "github.com/triztian/gomobile-v2target" ... error message is generated from srcimporter.go however the minimal compatibility notes mentions:

The entirety of the logic is – when operating in GOPATH mode, an unresolvable import statement containing a /vN will be tried again after removing the /vN if the import statement is inside code that has opted in to modules (that is, import statements in .go files within a tree with a valid go.mod file).

And the type-check error points towards the module not being tried again (for whatever reason), in this situation the imported package gomobile-v2mod has opted into modules and is inside the GOPATH so I'd expect for the retry to happen but removing the /v2 suffix.

After all of that I'm not denying that the root issue is the one you linked, but it could be that it's a different one.

The issue is github.com/triztian/gomobile-v2target imports github.com/triztian/gomobile-v2mod, but github.com/triztian/gomobile-v2mod then imports github.com/triztian/gomobile-v2mod/v2/subpkg

This will not work since there is no such package.

cc @eliasnaur @hyangah for comments about retrying without /v2

I have a bit more info, after playing a bit with the source, I narrowed the error to this line:

• https://github.com/golang/mobile/blob/master/cmd/gobind/main.go#L145

Basically a syntax-check is performed before any build is attempted, the syntax check happens without the minimal version compat that the modloads and several other modyyy packages provide when the go build command is ran on source files.

I think it might be possible to provide an Importer (interface) that is able to handle the module that opted in packages through an in-memory rewrite of the source for the package that has the exports
for the framework:

Example Excerpt: https://golang.org/pkg/go/types/#example_Info

fset := token.NewFileSet()
f, err := parser.ParseFile(fset, "fib.go", input, 0)
if err != nil {
	log.Fatal(err)
}

// Type-check the package.
// We create an empty map for each kind of input
// we're interested in, and Check populates them.
info := types.Info{
	Types: make(map[ast.Expr]types.TypeAndValue),
	Defs:  make(map[*ast.Ident]types.Object),
	Uses:  make(map[*ast.Ident]types.Object),
}

var conf types.Config
pkg, err := conf.Check("fib", fset, []*ast.File{f}, &info)
if err != nil {
	log.Fatal(err)
}

I've provided a working patch here, well at least for the 2 sample projects:

• golang/mobile@master...triztian:issue/33272

Basically it provides a custom importer that performs an in-memory rewrite of import paths of packages that have major versions in their paths i.e: "example.org/lib/v6" into "example.org/lib"

This does not add support for modules but rather it allows you to import packages that have opted into go modules and that have a vN path component without having to edit their sources.

To test the patch, just clone the branch from here https://github.com/triztian/mobile/tree/issue/33272 and reinstall the gobind command:

go install ./cmd/gobind

You may also need to re-init gomobile but I'm not entirely sure if thats necessary:

gomobile init

Setup

Clone the sample projects into your gopath (they've been updated):

• https://github.com/triztian/gomobile-v2target
• https://github.com/triztian/gomobile-v2mod

Then try and build the gomobile-v2target package:

The relevant proofs are that v2target imports v2mod and it has a v2 part in it's import:

// github.com/triztian/gomobile-v2target/export.go:8
v2mod "github.com/triztian/gomobile-v2mod/v2"

gomobile-v2target also imports one of it's subpackage with a v2 path component:

// github.com/triztian/gomobile-v2mod/math.go:4
import "github.com/triztian/gomobile-v2mod/v2/subpkg"

To build gomobile-v2target execute the following:

make clean run

You will need a swift compiler installed:

λ gomobile-v2target ~> swift --version
Apple Swift version 5.0.1 (swiftlang-1001.0.82.4 clang-1001.0.46.5)
Target: x86_64-apple-darwin18.6.0

Successful Output:

gomobile bind -target ios -work -a -v -tags "" .
WORK=/var/folders/7s/cnfg6ksj44gb3br_lc4v3gn40000gp/T/gomobile-work-132492778/go-build699643396
runtime/cgo
golang.org/x/mobile/internal/mobileinit
gobind
WORK=/var/folders/7s/cnfg6ksj44gb3br_lc4v3gn40000gp/T/gomobile-work-132492778/go-build206905632
runtime/cgo
golang.org/x/mobile/internal/mobileinit
gobind
WORK=/var/folders/7s/cnfg6ksj44gb3br_lc4v3gn40000gp/T/gomobile-work-132492778/go-build468413038
runtime/cgo
golang.org/x/mobile/internal/mobileinit
gobind
WORK=/var/folders/7s/cnfg6ksj44gb3br_lc4v3gn40000gp/T/gomobile-work-132492778/go-build230851473
runtime/cgo
golang.org/x/mobile/internal/mobileinit
gobind
write Mobile.framework/Versions/A/Headers/Mobile.objc.h
write Mobile.framework/Versions/A/Headers/Universe.objc.h
write Mobile.framework/Versions/A/Headers/ref.h
write Mobile.framework/Versions/A/Headers/Mobile.h
write Mobile.framework/Resources/Info.plist
write Mobile.framework/Versions/A/Modules/module.modulemap
WORK=/var/folders/7s/cnfg6ksj44gb3br_lc4v3gn40000gp/T/gomobile-work-132492778
swiftc -F. -framework Mobile -framework Foundation ./main.swift
-------------
./main
Testing
Result 21 + 21 =  42
Sum call: 18

There is a minimal swift file to test the framework and functionality:

import Mobile
import Foundation

print("Testing")
MobileMain()
print("Sum call: \(MobileSum(10, 8))")

I've not tested how it behaves when a vendor directory exists in the gomobile-v2target, happy to receive feedback and reports of issues, the test packages are quite simple so testing with more real-world complex packages would be beneficial.

We are discussing to support Go module at #27234

Is this still an issue?

Hi @hajimehoshi I can try and repro with the latest releases, I'll give it a go most likely this weekend. Dealing with iOS 14. Thank you for checking in!.

Assume this is not an issue anymore because there are modules that use gomobile but also in v2 mode, eg. fyne-io/fyne. Close as outdated.