bindings undefined: Message

[vaultec81]

When running go test with my codebase.
Platform: go version go1.23.1 windows/amd64 (windows 11)
Confirmed working on Linux and Mac osx.

> go test 

# github.com/supranational/blst/bindings/go
..\..\go\pkg\mod\github.com\supranational\[email protected]\bindings\go\rb_tree.go:130:18: undefined: Message
FAIL    command-line-arguments [build failed]
FAIL

[dot-asm]

I'm inclined to believe that this is a Windows-specific problem with Go compiler. Did you try different versions? Both latest 1.23.3 and something pre-1.23? I've tried a minimalist snippet that calls blst.Uniq and it works fine with 1.23.3 and 1.21.5... As in

package main

import (
        "fmt"
        blst "github.com/supranational/blst/bindings/go"
)

func main() {
        x := []blst.Message{[]byte("hello"), []byte("world")}
        fmt.Println(blst.Uniq(x))
}

Another possibility is interference with your antivirus. Race conditions introduced by its activity are not unheard of, nor the possibility that it has aversion to the whatever you try to do. For example I had .dll-s generated by Go compiler removed...

[LightFTSO]

Getting the same error message when attempting to compile a Go project on Linux 5.15
Tried go versions 1.21.8, 1.22.8, 1.22.9 and 1.23.3

Tried running the small program above with blst versions 0.13.11 and 0.13.3 and getting the same error

# github.com/supranational/blst/bindings/go
../go/pkg/mod/github.com/supranational/blst@v0.3.13/bindings/go/rb_tree.go:130:18: undefined: Message

[dot-asm]

Well, what can I say? In order to at the very least reason about a problem, I have to reproduce it. And I can't. As for reference to "Linux 5.15" I've never seen and even fail to imagine that a failure to compile a specific module but not a slew of others would depend on the Linux kernel version. I mean I interpret the reference as suggestion that the failure depends specifically on it. But all right, I can confirm that I can't reproduce it even with this specific kernel version. Not really surprising, because all a compiler, be it Go and or any other language, needs is to read and write files, which is the least kernel does. Hence I have to ask, what does "Linux 5.15" mean more specifically when you say it?

[LightFTSO]

The kernel version is mostly unimportant, other than the related glibc version it has I suppose, I just wanted to note that this happened to me on a Linux server since you had said this was a Windows-specific problem, it's not. It's a C/C++ compiler related issue.
If anyone else has this problem, I solved it by updating the toolchain to the latest available version, I'm using GCC.
Also try disabling any cross-compilation related flags and try again.

[dot-asm]

It's a C/C++ compiler related issue.

Hmm... How is it possible? The error does not involve C.go interface. Indeed, rb_tree.go makes no C.go calls and Message is a pure Go type, []byte...

I solved it by updating the toolchain to the latest available version

From which? I've just tried with gcc 5.4, and it worked...

[Geo25rey]

It seems this issue only shows up when a C compiler is not installed on the host system. It makes sense that the bindings wouldn't work without a C compiler since this library is written in C, but this is a very odd error to get if cgo can not find a C compiler.

[dot-asm]

Wow! Speaking of a blind spot :-) It boils down to the README issue, "To compile on Windows one has to have MinGW gcc on the %PATH%," which apparently can be generalized to "one has to have gcc." Ironically enough if one sets CC environment variable to a non-existent command such as "off", the error message is spot on, "executable file not found in PATH." Oh well...

Just in case for reference. Why gcc and not a C compiler. gcc is the explicitly pre-defined default. It can be overridden with a compatible replacement, but it's assumed that those who do know what they are doing.

Also for reference. Since it's specifically MinGW gcc on Windows, it's appropriate to mention how to verify that it's in fact a suitable one. gcc -dM -E -x c nul: | findstr "MINGW64" will tell.

[dot-asm]

gcc is the explicitly pre-defined default.

Correction. This is not universally true. It's the default for Linux and Windows packages, at least [for] ones downloaded from go.dev. Others default to cc and even clang. A note of caution in the context. clang for Windows comes in many flavours. One that would be suitable for go has to meet the same criteria as gcc.