I'm stumped on why the Go runtime would not be initialized inside my c-shared DLL.
I'm building a mixed Go and C DLL for windows, using go build -buildmode=c-shared On one instance of Windows 2016, everything runs fine, both with go1.12.5 and with go1.10.8. However, on an instance of Windows 10, and a second instance of Windows 2016, the exact same DLL will crash because it appears the Go runtime has not been initialized. I say I don't think the Go runtime has been initialized because 1) the init() routines have not been run even after DllMain has returned and subsequently the C host code has called into the main C function for the DLL. 2) At the point at which the C code first calls into the Go code, we crash. This takes down the process. I turned off DEP and I still get the crash. I wondering if anyone can shed some light on a) how I might understand when the Go runtime inside a DLL is supposed to be initialized; and b) how I might generate hypotheses as to why it isn't getting initialized under certain circumstances. Brainstorms welcome. Thanks for your thoughts! -J -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/99bac16d-47f2-4e9f-b2d3-329ff6691379%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
