Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/cgo: inconsistent definitions for C.sfColor #8133

Closed
mewmew opened this issue Jun 1, 2014 · 9 comments
Closed

cmd/cgo: inconsistent definitions for C.sfColor #8133

mewmew opened this issue Jun 1, 2014 · 9 comments
Labels
FrozenDueToAge
Milestone
Go1.4

Comments

@mewmew
Copy link
Contributor

mewmew commented Jun 1, 2014 

What does 'go version' print?
go version go1.3beta2 +1af13552a260 Sun Jun 01 13:57:46 2014 -0400 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

The p1 repo doesn't compile while the p2 repo does. The only difference is that p1 uses
multiple source files while p2 only uses a single source file.

1. go get github.com/mewmew/playground/p1
2. Prints the cgo error "inconsistent definitions for C.sfColor"

3. go get github.com/mewmew/playground/p2
4. Compiles without any errors.

The following files are present in the p1 repo:
* "a.go": http://play.golang.org/p/zQLkeed3id
* "b.go": http://play.golang.org/p/Uj09NA58LZ
* "Color.h": http://play.golang.org/p/fBghn23MNw

The following files are present in the p1 repo:
* "ab.go": http://play.golang.org/p/_nlL3rP6JB
* "Color.h": http://play.golang.org/p/fBghn23MNw

What happened?
p1 fails to compile, while p2 succeeds.

What should have happened instead?
Both p1 and p2 should compile without any errors.

Please provide any additional information below.
This issue may have been introduced recently, and if so most likely by rev
177ed19da89fc68391d6e2411163ffe777180637.
@mewmew
Copy link
Contributor Author

mewmew commented Jun 1, 2014

Comment 1:

Just noticed a minor copy-paste typo.
"p1" should be "p2" in the following paragraph:
The following files are present in the p1 repo:
* "ab.go": http://play.golang.org/p/_nlL3rP6JB
* "Color.h": http://play.golang.org/p/fBghn23MNw

@ianlancetaylor
Copy link
Member

Comment 2:

I'm not sure whether this is a bug or not.  In any case, the workaround seems
straightforward: don't import "C" in two different files in the same package.

Labels changed: added repo-main, release-go1.4.

@gpaul
Copy link
Contributor

gpaul commented Jun 2, 2014

Comment 3:

The first bad revision is:
changeset:   19460:177ed19da89f
user:        Russ Cox <rsc@golang.org>
date:        Wed May 28 14:04:31 2014 -0400
summary:     cmd/cgo: given typedef struct S T, make C.T and C.struct_S interchangeable
This is obviously a bug.

@ianlancetaylor
Copy link
Member

Comment 4:

I believe the problem here is specifically with a C .h file that does a typedef of an
untagged struct.  If the Go package has more than one file that import "C" and #include
that .h file, then we get this error from cgo.
In cgo terms, the problem is that the typedef has been given the Go name of the struct. 
Since the structs are untagged, they get Go names like _Ctype_struct___INDEX, where
INDEX differs.  So we appears to have the same typedef referring to two different
structs.

@ianlancetaylor
Copy link
Member

Comment 5:

Owner changed to @ianlancetaylor.

Status changed to Started.

@gopherbot
Copy link
Contributor

Comment 6:

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

@ianlancetaylor
Copy link
Member

Comment 7:

This issue was closed by revision 4e65f18.

Status changed to Fixed.

@dsymonds
Copy link
Contributor

dsymonds commented Jun 3, 2014

Comment 8:

This issue was closed by revision 317d45e3c8db.

@gpaul
Copy link
Contributor

gpaul commented Jun 3, 2014

Comment 9:

Thanks for fixing this Ian. It was more complicated than I thought.

@rsc rsc added this to the Go1.4 milestone Apr 14, 2015
@rsc rsc removed the release-go1.4 label Apr 14, 2015
dsymonds added a commit that referenced this issue May 11, 2015
@dsymonds
[release-branch.go1.3] cmd/cgo: use same Go type for typedef to anony…
e82cde2 
…mous struct

««« CL 102080043 / 256d975c53cb
cmd/cgo: use same Go type for typedef to anonymous struct

If we see a typedef to an anonymous struct more than once,
presumably in two different Go files that import "C", use the
same Go type name.

Fixes #8133.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/102080043
»»»

TBR=adg
CC=golang-codereviews
https://golang.org/cl/102100043
@golang golang locked and limited conversation to collaborators Jun 25, 2016
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
@ianlancetaylor @wheatman
cmd/cgo: use same Go type for typedef to anonymous struct
9b332a5 
If we see a typedef to an anonymous struct more than once,
presumably in two different Go files that import "C", use the
same Go type name.

Fixes golang#8133.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/102080043
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.4
Development

No branches or pull requests
6 participants
@gpaul @dsymonds @rsc @mewmew @ianlancetaylor @gopherbot