Bugs/support go1.20 darwin

[Bluebugs]

Description:

So apparently with go 1.20, we need to add -lresolv manually for some reason on darwin when any dependencies use the net package :-(

See golang/go#58416 and golang/go#58159

I know we could rely on the user having to set it manually, but I think that having it by default will help fyne-cross user and reduce the potential bug report. We could also detect if a project use the net package and add it only if needed, but I don't think it is a big deal to always add it.

[andydotxyz]

Are you sure about this? The linked bugs both seem to be referencing Xcode / gomobile - which is iOS not Darwin in our build tooling.
I am pretty sure this is not required for all Darwin as I have been using go 1.20 for months with no issue.

[Bluebugs]

Are you sure about this? The linked bugs both seem to be referencing Xcode / gomobile - which is iOS not Darwin in our build tooling.
I am pretty sure this is not required for all Darwin as I have been using go 1.20 for months with no issue.

There is two bugs report. One for ios and one for Darwin. As said, this only impact your application is you use the net package.

[lucor]

This will enable the flag also for build on macOS host. I think it is ok, but probably we need to adjust also the logic here

fyne-cross/internal/command/darwin.go

Line 246 in f76d5e2

if !cmd.localBuild {

[Jacalz]

I believe that my Geoffrey build 295 of Rymdport just failed due to this error. I don't see the logs myself but you can probably double-check them to see if that is the case.

EDIT: Apparently another issue according to Cedric. Geoffrey is already using this PR.

[andydotxyz]

To take another approach, this code was compiled on an Apple M2 without any special flags:

package main

import (
	"net"

	"fyne.io/fyne/v2/app"
	"fyne.io/fyne/v2/widget"
)

func main() {
	a := app.New()
	w := a.NewWindow("Hello")

	is, _ := net.Interfaces()
	w.SetContent(widget.NewLabel(is[0].Name))

	w.ShowAndRun()
}

(just FYI the mobile packager fyne package -os ios -profile "Wildcard Dev" works as expected on M2)

[andydotxyz]

I have also tested the same source code on a build for Darwin using Fyne-cross v1.3.0 and v1.4.0, both succeed without this patch.
I guess what I am struggling with is how to replicate the problem to test this fix with.

[Bluebugs]

The issue happen as described in both go ticket when you use anything in the net package as that requires dns resolution now provided by that library.

[Jacalz]

But the code mentioned above does use the net package?

[Bluebugs]

But the code mentioned above does use the net package?

That code is not going to require any dns resolution which is when you will see the problem.

[andydotxyz]

OK, the following compiles and runs with go 1.20.3 without any parameters...

package main

import (
	"log"
	"net"

	"fyne.io/fyne/v2/app"
	"fyne.io/fyne/v2/widget"
)

func main() {
	a := app.New()
	w := a.NewWindow("Hello")

	addr, err := net.LookupIP("google.com")
	if err != nil {
		log.Println("ERR", err)
	}
	w.SetContent(widget.NewLabel(addr[0].String()))

	w.ShowAndRun()
}

[Bluebugs]

As the original bug report point out, it is hard to have a small reproducible bug case and the one who opened the bug report are long time contributor to go. You might have luck with bigger application doing something. You can try mqttweather, maybe nomad or my application gotik. You could also just try to compile tailscale as that was the initial report on those bug.

[andydotxyz]

I don't know what to do with this - how can it progress without the ability to replicate the problem or confirm if it applies in our instance?

Is it possible for you to share more about how it was discovered or which projects do not work without the change?

[Bluebugs]

As I said try with big complex applications that use the network. Considering the bug report upstream come from tailscale developer. Just add tailscale to an application should lead to reproduce the problem, but mqttweather, rhymdport and nomad are likely also going to reproduce the problem.

[Bluebugs]

The release note for go 1.20 have been updated to include the need to add -lresolv when using cgo on mac with the net package: https://tip.golang.org/doc/go1.20 . This patch now follow official Go documentation and should not be blocked any longer.

[Jacalz]

But we are not building with -buildmode=c-archive? Rymdport uses the net package and I haven't seen anyone report any problems.

[Bluebugs]

My understanding is that option is added of you use any dependency that are static. That might be the case with fyne and glfw when using net with some dns resolution as that's what mqttweather does. As use of tailscale trigger it anyway, I am guessing it's because of some option they are setting somewhere to enable their library to be use by c code.

[Bluebugs]

As for rhymdport did you try building it on Mac with latest go lately?

[Jacalz]

I have been building it using Geoffrey

[Jacalz]

Which I realize probably is the reason that I haven't noticed it to be fair...

[andydotxyz]

I am trying to get back to things and it seems that this may have been updated on the Go docs, vis:

A consequence is that, on macOS, if Go code that uses the net package is built with -buildmode=c-archive, linking the resulting archive into a C program requires passing -lresolv when linking the C code.

This seems more clear. As far as I am aware we are not building C archives and then linking them into a Fyne application - so we should be OK to not make this change shouldn't we? This does explain why all my local builds kept working.