tinygo dev branch compilation with Fedora 43

[tinkerator]

Had some trouble installing the dev branch of tinygo on a Fedora 43 system. It failed like this:

$ go install --tags llvm21
# tinygo.org/x/go-llvm
/root/go/pkg/mod/tinygo.org/x/go-llvm@v0.0.0-20250422114502-b8f170971e74/ir.go:931:52: could not determine what C.LLVMConstMul refers to
/root/go/pkg/mod/tinygo.org/x/go-llvm@v0.0.0-20250422114502-b8f170971e74/ir.go:932:52: could not determine what C.LLVMConstNSWMul refers to
/root/go/pkg/mod/tinygo.org/x/go-llvm@v0.0.0-20250422114502-b8f170971e74/ir.go:933:52: could not determine what C.LLVMConstNUWMul refers to
/root/go/pkg/mod/tinygo.org/x/go-llvm@v0.0.0-20250422114502-b8f170971e74/ir.go:352:38: could not determine what C.LLVMLandingPadCatch refers to
/root/go/pkg/mod/tinygo.org/x/go-llvm@v0.0.0-20250422114502-b8f170971e74/ir.go:79:22: could not determine what C.LLVMLandingPadClauseTy refers to
/root/go/pkg/mod/tinygo.org/x/go-llvm@v0.0.0-20250422114502-b8f170971e74/ir.go:353:38: could not determine what C.LLVMLandingPadFilter refers to

Some searching later, and found this commit that claimed to be adding llvm21 support:

• tinygo-org/go-llvm@63740cf

So, I did this in my dev branch:

$ go get tinygo.org/x/go-llvm

which left me with this diff:

$ git diff
diff --git a/go.mod b/go.mod
index 7d4ea5f1..40b741ac 100644
--- a/go.mod
+++ b/go.mod
@@ -18,7 +18,7 @@ require (
        golang.org/x/sys v0.30.0
        golang.org/x/tools v0.30.0
        gopkg.in/yaml.v2 v2.4.0
-       tinygo.org/x/go-llvm v0.0.0-20250422114502-b8f170971e74
+       tinygo.org/x/go-llvm v0.0.0-20250929104024-00fb4309ddd2
 )
 
 require (
diff --git a/go.sum b/go.sum
index 8c2330c3..5d6bb756 100644
--- a/go.sum
+++ b/go.sum
@@ -60,3 +60,5 @@ gopkg.in/yaml.v3 v3.0.1 h1:fxVm/GzAzEWqLHuvctI91KS9hhNmmWOoWu0XTYJS7CA=
 gopkg.in/yaml.v3 v3.0.1/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=
 tinygo.org/x/go-llvm v0.0.0-20250422114502-b8f170971e74 h1:ovavgTdIBWCH8YWlcfq9gkpoyT1+IxMKSn+Df27QwE8=
 tinygo.org/x/go-llvm v0.0.0-20250422114502-b8f170971e74/go.mod h1:GFbusT2VTA4I+l4j80b17KFK+6whv69Wtny5U+T8RR0=
+tinygo.org/x/go-llvm v0.0.0-20250929104024-00fb4309ddd2 h1:PsrNpgfZNjozTahZwNrsRfdUxYPATE60vUn6UjK+/Jo=
+tinygo.org/x/go-llvm v0.0.0-20250929104024-00fb4309ddd2/go.mod h1:GFbusT2VTA4I+l4j80b17KFK+6whv69Wtny5U+T8RR0=

and the resulting tree builds with:

$ go install --tags llvm21

[deadprogram]

@tinkerator have you seen #5042?

Seems there are some issues still to address before it will work correctly.

[tinkerator]

I had not seen that, but I did suspect there might be more to this. Which is why I didn't make a pull request, only filed a bug.

[hoanga]

[snip]
and the resulting tree builds with:

$ go install --tags llvm21

While the tinygo binary will build, one thing that most likely will manifest (it did for me) when trying to build the current dev branch of tinygo using the llvm21 build tags is that the go-llvm package will attempt to use the requested tagged version correctly. However, tinygo also has llvm tag checks that are still a work in progress afaik for any version of llvm past llvm20.

I got the following output when checking the version of a tinygo binary built on the dev branch using llvm21 build tags and a locally updated go-llvm dependency. I think the branch in #5042 does address the version problem but I imagine that for more complete llvm21 support there are probably other gotchas:

  $ $HOME/go/bin/tinygo version
  panic: incorrect build: using LLVM version 21.1.5 in the tinygo.org/x/llvm package, an
  d version 20.1.8 in the ./cgo package

  goroutine 1 [running]:
  github.com/tinygo-org/tinygo/cgo.init.2()
          /home/user/src/git/tinygo/cgo/libclang.go:109 +0x25

[tinkerator]

I've also been using it from a Fedora 41 system (llvm19) and am running into a hang in less than a minute. I think it looks like #4974 on a pico2-ice board (RP2350B chip). So, clearly some stability issues to work through with the dev branch and that chip. The -scheduler tasks work around does clear that up though. If I get any more detail on that, I'll use that other bug to document that.