Go 1.21 builds fail when they use Go 1.18 Multi-Module Workspace dependency
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
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?
@jhheider that returns the same error for me
hmm.
$ 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.
Long shot, but if you run dsymutil, is it waiting on your to accept an updated license agreement from Apple?
that's a good idea - not sure how to trigger that
dsymutil
dsymutil --help
dsymutil --version
i'm on macOS ventura 13.5.2
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)
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 | shtea +go.dev go versiongo 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 [email protected]
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?
could be. the message is still odd. Does it work if you:
$ tea +go.dev~1.19
$ go build -o my-artifact main.go
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
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.
out of curiosity, are you also on darwin_arm64?
Definitely.
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
pantry issue. I would move there but it'll be lost in the spam.
gonna try upgrading from macOS 13.5.2 to 13.6 🤷🏼
14.0 released yesterday, if you're really risk-preferring. ;) No issues yet on my M2 Air....
@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
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
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.