Could you clarify your CPP and Go code.

//library files:
//tmp_log.h
#ifndef TMP_LOG_H
#define TMP_LOG_H

#ifdef __cplusplus
extern "C"
{
#endif

void tmp_log(const char* msg);

#ifdef __cplusplus
}
#endif

#endif

//tmp_log.cpp
#include "tmp_log.h"
#include <stdio.h>

extern "C"
{

void tmp_log(const char* msg)
{
printf("%s",msg);
}

}

struct Auto_Init
{
Auto_Init() {
tmp_log("++++ auto_init\n");
}
~Auto_Init() {
tmp_log("--- auto_fini\n");
}
};
static Auto_Init auto_init;

//compile
g++ -shared -fPIC -g -o libtmp_log.so tmp_log.cpp

//go files: go/src/tmp/log.go
package log

import(
"unsafe"
)

/*
#cgo CPPFLAGS: -I./tool -I.
#cgo LDFLAGS: -L./tool -L. -ltmp_log
#include "tmp_log.h"
#include <malloc.h>
*/
import "C"

func Log(msg string) {
cmsg := C.CString(msg)
C.tmp_log(cmsg)
C.free(unsafe.Pointer(cmsg))
}

//tool.go
package main

import (
"tmp/log"
)

func main() {
log.Log("go is running\n")
}

//run tool:
$ LD_LIBRARY_PATH=. ./tool
++++ auto_init
go is running

//c test, tool.c
#include "tmp_log.h"

int main(int argc,char* argv[])
{
tmp_log("*** tmp_log running\n");
return 0;
}
//compile
gcc -g -o c_tool tool.c -L. -ltmp_log
//run c tool
$ LD_LIBRARY_PATH=. ./c_tool
++++ auto_init
*** tmp_log running
--- auto_fini

@ianlancetaylor?

It's true that Go programs don't currently run the C++ static destructors of any code linked in via cgo.

I guess the way to fix this would be for cgo programs to call the C library exit function rather than the exit system call.

I agree we need to do this, although I am very sad about it. It didn't happen for Go 1.10, though, so at least there's that to be happy about.

It occurs to me that this will have an unfortunate interaction with log.Fatal: log.Fatal is defined to call os.Exit(1), which (after this is addressed) will invoke atexit hooks.

However, atexit hooks are not normally invoked if a program terminates abnormally, and I would argue that most uses of log.Fatal indicate abnormal termination. (I would argue that ideally log.Fatal should instead exit by raising SIGABRT.)

I don't think that interaction is fixable for Go 1, since the os.Exit behavior is clearly documented in the log API, but we should at least consider the interaction and perhaps revisit it for Go 2.

Just wanted to comment on other issues we have encountered due to this issue. When attempting to extract GCOV or mem track data for the C code, these tools require a C exit. Currently we have to explicitly call the exit() function in our test framework which prevents the go test code from finishing up. Please consider this when deciding the priority for the fix. We are looking forward to removing these workarounds once you have a fix. Thanks!

Just a note that currently when building with -race os.Exit will call the race detector __tsan_fini function which will call the C exit function and therefore will run destructors and atexit functions. In other words the current behavior varies depending on whether -race is used or not.