> The second downside may be a slight loss of ability to support very old targets. The most impactful of these will be 32-bit Windows since we are not sure if CGo (Go’s system that allows us to link to our C bits) will work properly on 32-bit Windows systems.
It should work fine - at least at $DAYJOB I ship a GOOS=windows GOARCH=386 CGO_ENABLED=1 binary, it passes all the test cases + no user complaints.
We have several C dependencies, mostly in two methods:
- Cygwin helps a lot by providing a GNU make that works with CC=mingw-w64 (i.e. no cygwin1.dll dependency) and we can simply link these extra .o by setting `-extldflags "-lxxxx"` on `go build` invocation; and/or
- Put .c files in a Go package and build with CGO as-is (e.g. github.com/datadog/zstd package and others). More convenient but some limitations on CFLAGS for security reasons post-1.10.
All works fine and was not particularly complex to set up. GC changes have caused us to need more explicit `runtime.KeepAlive` calls after CGO interop however.
It should work fine - at least at $DAYJOB I ship a GOOS=windows GOARCH=386 CGO_ENABLED=1 binary, it passes all the test cases + no user complaints.