go: cmd/cgo: undefined reference for C function with -buildmode=c-archive

I was able to achieve the requested result (a Go static library which can be invoked by a C main program and can, in turn, call exposed C functions in the main program) by doing the following:

In the Go code, export functions as normal with the //export directive:

//export myGoFunc
func myGoFunc() {
    C.myCFunc()
}

Import cgo, and in the import declarations, declare the external C functions you want to call from Go.

// extern void myCFunc();
import "C"

Then, the important part: the cgo code needs to be compiled with the linker flag -unresolved-symbols=ignore-all (for Linux GCC, on Mac the equivalent flag is -undefined,dynamic_lookup). You could probably do this at the build command somehow, but its more clear to add it to the cgo declaration like this:

// #cgo linux LDFLAGS: -Wl,-unresolved-symbols=ignore-all
// #cgo darwin LDFLAGS: -Wl,-undefined,dynamic_lookup
// extern void myCFunc();
import "C"

These linker flags allow the Go code to successfully compile without having the external C functions defined anywhere, as they get looked up later when the C program they’re in gets linked with the Go library.

Then, finally, build the Go static library with -buildmode=c-archive (specifically, my build command is go build -o mylib.a -buildmode=c-archive src.go) and link it to a C program in which the extern function(s) are defined.

So far this seems to work correctly for me, but I’d like to know from Go experts if there is anything wrong with this solution. Will certain features of Go, like goroutines/scheduling or memory management, not work correctly? They appear to be working, but I don’t know enough about the technical details of Go to be sure…

omg, finally i foud

// export

is wrong but the follow is rigth

//export

just don’t add space after “//”

Until there is a better option, you can get it working by compiling the C code with -c and use that to compile the Go code and than link together those. For that, you have to have the declarations of the functions exported from the Go source. I did that by hand. I was even lazy enough to simply use int on both sides, which works on most architectures.

I would suggest to create a feature request to be able to use this:

import "C"

//import cadd
func cadd(a C.int, b C.int) C.int

// for use in other packages with Go types
func Cadd(a int, b int) int {
  return int(cadd(C.int(a), C.int(b)))
}

@hajimehoshi I had your same problem and I created a fake dll library to link using dlltool. Es.

 dlltool -d ./your-definition-libray.def -y your-library.a

dlltool is part of MinGW the .def file contains all the symbols you need. Hope this could help you.

@NickNaso I don’t know for sure – I’m not very experienced with MSVC – but perhaps try the /FORCE:UNRESOLVED argument instead of the -unresolved-symbols=ignore-all argument. It appears to do something similar, at least by what the documentation says.

Alternatively, you might be able to use MinGW + GCC on Windows to compile with GCC instead of MSVC. Then the LDFLAGS should be the same as on Linux.

Good luck!

@zelbrium I don’t think there is anything wrong with your solution. There are some oddball cases where it might fail if you want to use internal linking (-ldflags=-linkmode=internal), but that is not the default, and there is no reason for you to use it.