cmd/go: -buildmode=c-archive should work on windows

[jimpark]

We'd like a way to use go as a library language on Windows. Since there is already issue #11058 that addresses the need for the c-shared build mode for generating DLLs, I am adding this request for getting static library support.

[nadiasvertex]

Submitted a patch at https://go-review.googlesource.com/#/c/18057/

[gopherbot]

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

[nadiasvertex]

I've added 32-bit support to this code, however it no longer builds at all when I set GOARCH=386.

I get:

$ go build -v -x -buildmode=c-archive -o test.a calc.go
can't load package: no buildable Go source files in <path>

GOARCH=amd64 works perfectly fine.

Any ideas?

[alexbrainman]

I can see rt0_windows_amd64.s changed in CL 18057. For 386 support, I suspect you want to make similar changes to rt0_windows_386.s ay the very least. No?

Alex

[nadiasvertex]

I'm sorry, I should have been more clear. I have not pushed the 32-bit changes into the CL. I can do that, if you like. I made numerous changes, including rt0_windows_386.s. I admit that it is hard to diagnose a problem blind. I was thinking I just made some obvious beginner's mistake and perhaps you would might have seen something like this before.

[ianlancetaylor]

It's just a guess, but perhaps you are getting no buildable Go source files in <path> because you have set GOARCH such that you are cross-compiling, but you did not explicitly set CGO_ENABLED=1.

[nadiasvertex]

That was it exactly. The 32-bit Windows API does not support some of the runtime features I wrote for initialization. I will have to rewrite parts of that code.

[nadiasvertex]

I am encountering very strange errors. Basically, hundreds of errors that look like:

'blah' referenced in section '.text' of 'blah' defined in discarded section '.text' of 'blah.../libkernel.a

I've tried to look through why this may be happening, but I'm afraid that I haven't come up with anything. Any ideas?