cmd/cgo: "inconsistent definitions for C.CString" errors #17723
Comments
ianlancetaylor
changed the title
|
Interestingly enough, it goes away if you put the contents of color.go into x11.go. Might be similar to #8133? |
|
I've found a workaround: If I replace all |
|
@ainar-g - That "one file" behavior seems to make some sense as it appears the parser caches types per file. Thanks for the workaround! I'm leaning toward wanting to investigate this further, as my previous random workaround worked at first, then stopped working! That will be good to let me continue along, at any rate... |
|
The problem occurs when two files refer to Testing a fix now. |
|
CL https://golang.org/cl/32536 mentions this issue. |
|
Might it be good, in addition, to do some more tailored comparison of Name in cmd/cgo/main.go than |
|
Thanks, yes, we would need examples to make any changes here. The complexities of merging the type systems of the two different languages are difficult to reason about in the abstract. |
Something severely funky is happening with cgo as I try to create bindings for the X Windows library.
I know there is a bug relating to struct definitions where you get "inconsistent definitions", but this is a conflict for an object in the default C package which I am certainly not defining (and that text does not appear in the cgo include headers, nor does it appear as a symbol in the target library!)
What is really quite strange about this, is that it will randomly appear and disappear as I add functions to the library - it seems to be pretty dependent on some state which we might call "random" (possibly position of defs in the cgo generated sources?), but is reproducible on a single codebase state. I cannot seem to create a MCVE because of this, but I have uploaded the source of the project so far to https://github.com/dtromb/x11-cgo-bug - attempting to compile this should reproduce the issue.
I have really no idea how to debug this. First, I grepped through the generated cgo source, expecting to find a duplicate definition of
CString()(or rather the C-mangled-name function implementing it). I did not - there was only one. I then noticed that the error is emitted from the cgo binary after areflect.DeepEqual()comparison of the conflicting*main.Nametypes. I tried rewritingDeepEqual()to provide some debugging information - and that was not helpful (package access rules thwarted the implementation). Next, I wrote a function to dump theNamestructure to a string, and all of theast.Exprand friends so that we can see the exact differences. I've attached those dumps as files here.fail.txt
fail2.txt
As you can see, there is a
Typedeffield in theFuncTyperecord being set to "XPointer"; this corresponds, I believe, to the return type of theCString()implementation.This is something of a clue, as Xlib does define an
XPointertype, as follows:, so it is at least /plausible/ that something somewhere is mistaking this for the actual return type of
CString(). I'm sorry to say my trail ended here though, as I really don't know enough about the Go parser or these specific structures to progress easily further...What version of Go are you using (
go version)?go version go1.7.3 linux/amd64
What operating system and processor architecture are you using (
go env)?GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/dtrombley/go/path"
GORACE=""
GOROOT="/home/dtrombley/go/root"
GOTOOLDIR="/home/dtrombley/go/root/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build434390939=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
What did you do?
I am attempting to compile a valid Go program with cgo interfaces to the X library.
What did you expect to see?
Completed Proper compilation.
What did you see instead?
cgo emits: "inconsistent definitions for C.CString"
The text was updated successfully, but these errors were encountered: