Go 1.21 builds fail when they use Go 1.18 Multi-Module Workspace dependency

[kevinmichaelchen]

I'm building a Go project with

$ tea go version
go version go1.21.1 darwin/arm64

$ tea go build -o my-artifact main.go

but getting the following error in response:

# command-line-arguments
deprecated: use ${TEA_DIR:-$HOME/.tea} instead
/Users/kevin.c/.tea/go.dev/v1.21.1/pkg/tool/darwin_arm64/link: /Users/kevin.c/.tea/go.dev/v1.21.1/pkg/tool/darwin_arm64/link: running dsymutil failed: fork/exec deprecated: use ${TEA_DIR:-$HOME/.tea} instead
/Library/Developer/CommandLineTools/usr/bin/dsymutil: no such file or directory

But that file does exist!

$ ls -la /Library/Developer/CommandLineTools/usr/bin/dsymutil

-rwxr-xr-x  1 root  wheel  75270368 May 11 23:58 /Library/Developer/CommandLineTools/usr/bin/dsymutil

Sources

• Tea package source for Go
• Homebrew Go formula
• Occurrences of dsymutil in the golang source code

[jhheider]

I think error is probably mistake, that if the exec failed it assumed the bin didn't exist. Does it, out of curiousity, make a difference if you run TEA_DIR=$HOME/.tea tea go build -o my-artifact main.go?

[kevinmichaelchen]

@jhheider that returns the same error for me

[jhheider]

hmm.

[jhheider]

$ tea --version
tea 1.0.0-alpha.4
$ tea go version
go version go1.21.1 darwin/arm64
$ tea go run foo.go
Hello World
$ tea go build -o foo foo.go
$ ./foo
Hello World

works for a simple example for me.

[jhheider]

Long shot, but if you run dsymutil, is it waiting on your to accept an updated license agreement from Apple?

[kevinmichaelchen]

that's a good idea - not sure how to trigger that

dsymutil
dsymutil --help
dsymutil --version

[kevinmichaelchen]

i'm on macOS ventura 13.5.2

[jhheider]

Very suspicious. I just did the following on my laptop:

• upgrade to macos 14 (because i did)
• sudo rm -rf /usr/local/bin/tea ~/.tea/.local (cleanup)
• curl -fsS https://tea.xyz | sh
• the above (which worked for me)

[kevinmichaelchen]

Ran those commands, same error. Even tweaked it a bit, but same error

• sudo rm -rf /usr/local/bin/tea ~/.tea/
• curl -fsS https://tea.xyz | sh
• tea +go.dev go version
  • go version go1.21.1 darwin/arm64
• tea +go.dev go build -o my-service main.go

errors look a bit different if i pin the version +go.dev@1.20

[kevinmichaelchen]

OK... so builds work fine when i've got no deps in go.mod

https://github.com/kevinmichaelchen/tea-go-1.21

so maybe it's something related to one of the dependencies in my go.mod and it being on go 1.19???

i have no idea -- maybe this isn't definitely a Tea issue and more of a Go issue?

[jhheider]

could be. the message is still odd. Does it work if you:

$ tea +go.dev~1.19
$ go build -o my-artifact main.go

[kevinmichaelchen]

that returns an error, but not the one we're looking for

go: errors parsing go.mod:                                       
/Users/kevin.c/dev/github.com/kevinmichaelchen/tea-go-1.21/go.mod:3: invalid go version '1.21.1': must match format 1.23

[jhheider]

Interesting. That didn't pick up ~1.19. But that suggests that line 3 in your go.mod should say 1.21 rather than 1.21.1. I've seen that in go in some places, where it doesn't want you to be specific about patch levels.

[kevinmichaelchen]

out of curiosity, are you also on darwin_arm64?

[jhheider]

Definitely.

[kevinmichaelchen]

quoting myself here lol

maybe this isn't definitely a Tea issue and more of a Go issue?

can confirm this is a Tea issue. ran the following

# succeeds
/opt/homebrew/Cellar/go/1.21.1/bin/go \
  build -o my-app main.go

# fails
tea go \
  build -o my-app main.go
tea +go.dev go \
  build -o my-app main.go

[mxcl]

pantry issue. I would move there but it'll be lost in the spam.

[kevinmichaelchen]

gonna try upgrading from macOS 13.5.2 to 13.6 🤷🏼

[jhheider]

14.0 released yesterday, if you're really risk-preferring. ;) No issues yet on my M2 Air....

[kevinmichaelchen]

@jhheider seems to be an issue with go 1.18 multi-module workspaces

i reproduced the issue here...

https://github.com/kevinmichaelchen/tea-go-1.21/pull/1

[kevinmichaelchen]

it's strange that i'm still seeing references to TEA_DIR even though I'm using pkgx... maybe I'm forgetting to clean something up?

i also tried nuking my global Go cache/deps and explicitly setting the TEA_DIR var

sudo rm -rf $(go env GOPATH GOMODCACHE)
TEA_DIR=$HOME/.pkgx pkgx go build -o my-service main.go

[jhheider]

At this point, it might be sane to rm -rf ~/.tea ~/.pkgx and reinstall pkgx. I did that after messing around with cross-conversion, to save myself the additional pain. I'll try your multi-module test when I get a chance.