If it's of any help in tracking it down, the following work around appears to do fine:

package main

/*
#include <stdlib.h>
typedef void (*destructor)(void*);
destructor std_free() {
    return free;
}
static void my_func(destructor d, char *p) {
    d(p);
}
*/
import "C"

func main() {
    C.my_func(C.destructor(C.std_free()), C.CString("test"))
}

EDIT: of course I meant to actually call std_free not just reference it

The problem is that Go tip generate write barriers for the variable _Cfpvar_fp_free:
//go:linkname __cgo_free free
//go:cgo_import_static free
var __cgo_free byte
var _Cfpvar_fp_free unsafe.Pointer = (unsafe.Pointer)(unsafe.Pointer(&__cgo_free))

using LEAQ instruction (see the LEQA at offset 0x55):
0x004a 00074 (gotypes.go:33) LEAQ ""._Cfpvar_fp_free+0(SB),BX
0x0051 00081 (gotypes.go:33) MOVQ BX,(SP)
0x0055 00085 (gotypes.go:33) LEAQ free+0(SB),BX
0x005c 00092 (gotypes.go:33) MOVQ BX,8(SP)
0x0061 00097 (gotypes.go:33) PCDATA $0,$0
0x0061 00097 (gotypes.go:33) CALL ,runtime.writebarrierptr(SB)
...
rel 88+4 t=9 free+0 // 9 is R_PCREL

Mach-O doesn't support this kind of pc relative relocation of a dynamic
symbol.

I see multiple possible ways to fix this, for example:

1. use static initialization for static addresses, as they can't possibly affect GC,
   thus no need for write barriers
2. encode the LEAQ externalSymbol+0(SB), REG as MOVABS $address, REG

Suggestions?

Mach-O doesn't support this kind of pc relative relocation of a dynamic symbol.

Is this the same issue as #8791?

CL https://golang.org/cl/11693 mentions this issue.

By applying the patch, https://github.com/gwenn/goreadline builds correctly.
Should I close this issue ?

i can confirm that the patch fixes the problem I reported in #10015, a duplicate of this one.