tinygo
tinygo copied to clipboard
Code is not compiling after upgrading to tinygo v0.29.0
I posted an issue in tinygo repo, as I believe it's related to compiler, at least when it comes to Windows. However I'm not sure about Linux.
So I just cross-post original issue here as you guys may know better the reason which causing it:
I have some code using knqyf263/go-plugin which compiles with no problem ~~on both Windows and Linux platforms~~ using tinygo v0.28.1. However it stopped working after upgrade to v0.29.0:
~~On Windows:~~
task: [plugin] tinygo build -o wasm/plugin.wasm -scheduler=none -target=wasi --no-debug ./wasm
# os
c:\tinygo\src\os\stat_linuxlike.go:18:6: fillFileStatFromSys redeclared in this block
c:\tinygo\src\os\stat_linux.go:14:6: other declaration of fillFileStatFromSys
c:\tinygo\src\os\stat_linuxlike.go:50:6: timespecToTime redeclared in this block
c:\tinygo\src\os\stat_linux.go:46:6: other declaration of timespecToTime
c:\tinygo\src\os\stat_linuxlike.go:55:6: atime redeclared in this block
c:\tinygo\src\os\stat_linux.go:51:6: other declaration of atime
exit status 1~~
On Linux:
task: [plugin] tinygo build -o wasm/plugin.wasm -scheduler=none -target=wasi --no-debug ./wasm
tinygo:wasm-ld: warning: function signature mismatch: log
>>> defined as (i32, i32) -> i64 in lto.tmp
>>> defined as (f64) -> f64 in /usr/local/lib/tinygo/lib/wasi-libc/sysroot/lib/wasm32-wasi/libc.a(log.o)
task: [run] go build && ./test-wasm-plugin
Caught panic as *fmt.wrapError: wasm error: unreachable
wasm stack trace:
.interface:{HttpGet:func:{named:context.Context,pointer:named:gitlab.com/***/test-wasm-plugin/api.HttpGetReq}{pointer:named:gitlab.com/***/test-wasm-plugin/api.HttpGetResp,named:error},Log:func:{named:context.Context,pointer:named:gitlab.com/***/test-wasm-plugin/api.LogReq}{pointer:named:github.com/knqyf263/go-plugin/types/known/emptypb.Empty,named:error}}.Log$invoke(i32,i32)
.(main.MyPlugin).SendRequest(i32,i32)
.greeter_send_request(i32,i32) i64
Upd.: problem on Windows was due to broken installation please disregard this part.
I can confirm that compiler is broken at least on Windows, for instance this simple program does not compile (with same error messages):
package main
import "fmt"
func main() {
fmt.Println("Hi from wasm!")
}
Result:
task: [build-tinygo] tinygo build -o test.wasm -scheduler=none -target=wasi --no-debug
# os
c:\tinygo\src\os\stat_linuxlike.go:18:6: fillFileStatFromSys redeclared in this block
c:\tinygo\src\os\stat_linux.go:14:6: other declaration of fillFileStatFromSys
c:\tinygo\src\os\stat_linuxlike.go:50:6: timespecToTime redeclared in this block
c:\tinygo\src\os\stat_linux.go:46:6: other declaration of timespecToTime
c:\tinygo\src\os\stat_linuxlike.go:55:6: atime redeclared in this block
c:\tinygo\src\os\stat_linux.go:51:6: other declaration of atime
task: Failed to run task "build-tinygo": exit status 1
Not sure about warning and panic I have on Linux, however I double-checked that downgrading to tinygo v0.28.1 and go1.20 makes everything work again.
The problem on Windows appears to be that you installed the new release over the old one. This doesn't work, because now you have leftover files from the old install that interfere with the build (stat_linux.go was renamed to stat_linuxlike.go). The fix is to remove the install directory entirely and do a fresh install.
For Linux I don't know exactly. Maybe tinygo clean will fix it. If not, check whether you have a log function defined somewhere. It looks like you have, and it interferes with the log function in the libc (I recommend renaming your log function).
@aykevl thanks, on Windows, I re-installed tinygo completely and now have same errors as on Linux:
- Warning when compiling:
wasm-ld: warning: function signature mismatch: log >>> defined as (i32, i32) -> i64 in lto.tmp >>> defined as (f64) -> f64 in c:\tinygo\lib\wasi-libc\sysroot\lib\wasm32-wasi\libc.a(log.o) - Panic when run:
Caught panic as *fmt.wrapError: wasm error: unreachable wasm stack trace: .interface:{HttpGet:func:{named:context.Context,pointer:named:gitlab.com/***/test-wasm-plugin/api.HttpGetReq}{pointer:named:gitlab.com/***/test-wasm-plugin/api.HttpGetResp,named:error},Log:func:{named:context.Context,pointer:named:gitlab.com/***/test-wasm-plugin/api.LogReq}{pointer:named:github.com/knqyf263/go-plugin/types/known/emptypb.Empty,named:error}}.Log$invoke(i32,i32) .(main.MyPlugin).SendRequest(i32,i32) .greeter_send_request(i32,i32) i64
tinygo clean didn't help.
There might be something related specifically to knqyf263/go-plugin and generated code, however it looks quite suspicious that everything works flawlessly with previous version of tinygo. Shouldn't it happen on both unless it's related to some breaking changes, which I'm not aware of?
It appears that for some reason Log method is conflicting with some log function in libc. This little change solves the issues above:
So the open questions are:
- Why this worked with no problems on tinygo v0.28.1?
- Are there any other reserved (?) function names such as
login libc which can't be used as method names?
Why this worked with no problems on tinygo v0.28.1
After some researching, I think the reason is basically this generated code when we use Log method name to become a host function:
//go:wasm-module env
//export log
//go:linkname _log
func _log(ptr uint32, size uint32) uint64
@aykevl I saw that there were some changes in using of export directive, should this approach be changed in some way in order to reflect recent improvements and potentially avoid name conflicts?
There might be something related specifically to
knqyf263/go-pluginand generated code, however it looks quite suspicious that everything works flawlessly with previous version of tinygo.
The code was incorrect, but was working due to a bug in TinyGo. The bug got fixed, and now the package is not compiling anymore. So yeah, it's a breaking change in the sense of "you accidentally relied on a bug in TinyGo".
Why this worked with no problems on tinygo v0.28.1?
Because previous TinyGo versions had a bug that allowed this code.
Are there any other reserved (?) function names such as
login libc which can't be used as method names?
Yes, all other function names that could possibly exist in the binary (this includes the entire libc for example).
It's best to make sure they have a unique prefix, for example myuniquepackagename_log instead of just log.