Linking Go with Windows shared library - c++

Question

I've been crash-learning Go (1.15.8) on Windows for the past two days, and I'm at the point where I need to call C (C++) from my Go program. I've scoured the Interewebs, but almost everything is for Linux--I'm on Windows.
Instead of monkeying with golang.org/x/sys/windows to try and wrap these calls, I've created a shared library that makes a number of pretty low-level Win32 API calls. It is compiled as C++, but it has a C interface that calls into the C++ function. This interface method has been wrapped in extern "C" to make it visible to Go. The header file has only this C interface function defined.
My cgo settings within the Go file look like:
// #cgo CFLAGS: -Imetadata
// #cgo LDFLAGS: -L. -lmetadata -lkernel32 -lole32
The shared library is called "metadata.dll". I compiled it with:
cl /c /EHsc /DUNICODE /D_UNICODE /Imetadata metadata/metadata.cpp
link /DLL /OUT:metadata.dll metadata.obj /MACHINE:X64 /INCREMENTAL:NO "kernel32.lib" "ole32.lib"
The library header looks like:
#pragma once
#ifdef __cplusplus
extern "C" {
#endif
int metadata_comment(const char* filename, int is_dir, char* comment, int buffer_size);
#ifdef __cplusplus
} // extern "C"
#endif
When I try to build (or just run, for that matter), I get just:
# command-line-arguments
abnormal program termination
I tried using the -x flag to see if I could get more information, but there's really nothing happening there. As soon as it lists the env values, it dumps into the above message. Before aborting, my build line with the -x option looks like:
WORK=N:\Temp\go-build527705418
mkdir -p $WORK\b001\
cd M:\Projects\ls
TERM='dumb' CGO_LDFLAGS='"-g" "-O2" "-LM:\\Projects\\ls" "-lmetadata" "-lkernel32" "-lole32"' "D:\\Go\\pkg\\tool\\windows_amd64\\cgo.exe" -objdir "$WORK\\b001\\" -importpath command-line-arguments -- -I "$WORK\\b001\\" -g -O2 "-IM:\\Projects\\ls\\metadata" "M:\\Projects\\ls\\ls.go"
I've been using github.com/arrieta/golang-cpp-basic-example as a reference for this (but even there, he's using gcc and Linux).
Might this be a bug in this version of Go, or am I just doing something stupid? I was blazing along really well until I hit this brick wall. Any help or insights will be appreciated.

Answer 1

Visual Studio can debug DLL's - just tell it what command line is needed to start the executable which will load your DLL. That can be a Go executable; VS will know that it's just debugging metadata.dll. Since this is a native debugger, it will catch the crash as it happens.

Answer 2

Ok, this is straight from the horse's mouth:
Go uses and supports only mingw-w64 on windows, so you can only link
things that you can link with mingw and static libs created with msvc
isn't one of them. You can however dynamic link to msvc dlls.
So, what I have discovered is that, on Windows, (c)Go will not link directly to either a static or a dynamic library. Explicit MSVC support is something they are working on, but if you want to directly link to either kind of library, you currently have to use the mingw environment. He mentions that (c)Go will "link" to a dynamic library (i.e., DLL), but I could not get it to even do that.
However, what you can do is build your DLL with whatever lower-level accesses you need, and then load that DLL at runtime and access your visible function in your Go code. Here is some example Go code based on what I'm using now that completely solved my problem:
dll_metadata := windows.MustLoadDLL("metadata.dll")
proc_metadta := dll_metadata.MustFindProc("metadata_comment")
result := ""
const METADATA_BUFFER_SIZE = 1024
buffer := make([]byte, METADATA_BUFFER_SIZE)
var pBuffer *byte
pBuffer = &buffer[0]
len, _, _ := proc_metadata.Call(
uintptr(unsafe.Pointer(windows.StringToUTF16Ptr(filename))),
uintptr(unsafe.Pointer(pBuffer)),
uintptr(METADATA_BUFFER_SIZE))
if len != 0 {
r := UTF16BytesToString(buffer)
result = r[:len]
}
I hope this helps others who might also be struggling with Go on Windows while trying to learn from the available examples which are virtually all based on some UN*X variant.