Indeed, confirming data: I can re-create the crashing circumstances immediately by renaming C:\Go to C:\Go1.12.5.
On Tuesday, May 14, 2019 at 3:53:10 AM UTC+2, Jason E. Aten wrote: > > Installing the Go build environment locally on the deploy host fixed the > crash. I'm guessing it is probably the missing timezone data on Windows, as > in > > https://github.com/golang/go/issues/21881 > > or some other assumption by the runtime inside the DLL that it is running > on a machine that has the Go build environment installed. > > On Saturday, May 11, 2019 at 2:42:40 AM UTC+2, Ian Lance Taylor wrote: >> >> On Fri, May 10, 2019 at 1:43 PM Jason E. Aten <j.e...@gmail.com> wrote: >> > >> > 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; >> >> In c-shared mode the function _rt0_amd64_windows_lib is supposed to be >> called when the DLL is initialized. That function, in >> runtime/rt0_windows_amd64.s, should start a new thread that will >> initialize the Go runtime. >> >> The Windows support for c-shared is very new, and perhaps there are >> some circumstances in which it does not arrange for >> rt0_amd64_windows_lib to be run when the DLL is loaded. I'm not sure >> but I think the code that sets this up is (*peFile).addInitArray in >> cmd/link/internal/ld/pe.go. So make sure that method is being called, >> and then make sure it is doing the right thing. >> >> Ian >> > -- 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/43733e84-b762-4c33-a8bc-047689bfdb4a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
