cmd/go: 'go build' of a SWIG only package fails with 'C source files not supported without cgo'

[michael-schaller]

What version of Go are you using (go version)?
go version devel +f34964e Sun Dec 21 00:24:39 2014 +0000 linux/amd64

What operating system and processor architecture are you using?
linux/amd64 (Ubuntu 14.04 amd64)

What did you do?
Run 'go build' on this example: https://gist.github.com/michael-schaller/94a2ee39bde248c83742

What did you expect to see?
That 'go build' or 'go test' work as previously under Go 1.4 and earlier.

What did you see instead?
The error message 'C source files not supported without cgo'.

What else?
SWIG version: 3.0.3 (commit 93d58cd3ed1cc2cf0490e95d43eed4e8de62763d; master on 2014-12-21)

[emidoots]

I think there is an issue for this already somewhere.. but I can't find it.

AFAIK you can throw an empty file like this one into your package directory as a workaround:

package foo

import "C"

[michael-schaller]

@slimsag I couldn't find an issue for this bug either. Thanks for adding the missing workaround.

[davecheney]

If the question is "how to stop go considering a directory containing only
C source a Go package" the answer is, a use build tags, b,rename the
directory, a prefix of . or _ will do.

If this was not the question, ignore me.
On 22 Dec 2014 15:54, "Michael Schaller" notifications@github.com wrote:

@slimsag https://github.com/slimsag I couldn't find an issue for this
bug either. Thanks for adding the missing workaround.

—
Reply to this email directly or view it on GitHub
#9410 (comment).

[michael-schaller]

@davecheney Clarification:
This issue is about a package with Go/SWIG code that doesn't use cgo at all. This works under previous Go releases but the Go master gives the error 'C source files not supported without cgo' on a 'go build' run. The temporary workaround is to add a dummy 'import "C"' to bypass this error. See also the example code under: https://gist.github.com/michael-schaller/94a2ee39bde248c83742

[michael-schaller]

The commit that caused this regression is: 729847c

@rsc
Russ, I think the code you've removed in the gcToolchain.cc method is still needed for SWIG.

[ianlancetaylor]

It's more complicated than that. The current version of SWIG generates code that is expected to be compiled by 6c, but 6c no longer exists. Simply fixing gcToolchain.cc won't help.

[michael-schaller]

I see. So the C compilers have been already removed for Go 1.5. Unfortunately the doc http://golang.org/s/dev.cc doesn't mention what needs to happen to support SWIG again.

Ian, what is the plan for SWIG? Is there a bug to follow other than this bug?

[ianlancetaylor]

I know of three possible approaches to fix SWIG (there is no tracking bug).

The first approach is to change SWIG to generate cgo input rather than doing the same thing as cgo. This is the best approach because it should fix most SWIG issues for all time. It is probably also more complicated.

The second approach is for the go tool to convert the _gc.c file generated by SWIG into Go. This is a mechanical translation, and will not require a new SWIG release. It's very ugly.

The third approach is to change SWIG to add the _gc.c information to the .go file. This is not very satisfactory as the result will not work with versions of Go before 1.4.

[michael-schaller]

Hmm....

The second approach doesn't really sound like a viable solution to me. Letting the go tool parse the '_gc.c' file just to generate a Go source file does sound wrong to me as SWIG should generate working wrapper source out of the box.

The third approach might be a viable solution but I'm not sold on the idea. I'm sure that SWIG could be changed to support pre-1.4 and post-1.3 simultaneously. In the worst case a SWIG command line switch like -py3 for Python 3 could switch between the versions. It looks relatively straight-forward to generate a Go source file similarly to the '_gc.c' file as 'runtime.h' and 'cgocall.h' have been replaced with / converted to Go equivalents. Maintaining two code paths in SWIG doesn't sound like a good idea though.

The first approach does sound good to me and relatively straight-forward. If I'm not mistaken then SWIG has to generate a header file for cgo instead of a '_gc.c' file and the '.go' source file needs to make cgo calls (C. calls) instead of using _cgo_runtime_cgocall.

In any case the go tool will need to be changed though.
Ian, did I miss anything? Which Go versions would be covered with the first approach?

[ianlancetaylor]

The point of the second approach is that it works for all versions of Go.

I'm sure that SWIG could be changed to support pre-1.4 and post-1.3 simultaneously.

Using cgo, yes; otherwise, no. I'm really pretty sure I'm right about this. A command line option is painful for users, but it is true that we could have the go tool pass it.

The first approach should work for all versions of Go when SWIG is invoked manually. It would not work for older versions of Go when using the older go tool. The main benefit of this approach is that it would work for all foreseeable versions of Go going forward, unlike the other approaches. Go is not going to break existing cgo programs.