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.

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

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

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

Comments

@mewmew
Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

commented Jun 1, 2014

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Jun 2, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Jun 2, 2014

Comment 5:

Owner changed to @ianlancetaylor.

Status changed to Started.

@gopherbot

This comment has been minimized.

Copy link

commented Jun 2, 2014

Comment 6:

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

This comment has been minimized.

Copy link
Contributor

commented Jun 2, 2014

Comment 7:

This issue was closed by revision 4e65f18.

Status changed to Fixed.

@dsymonds

This comment has been minimized.

Copy link
Member

commented Jun 3, 2014

Comment 8:

This issue was closed by revision 317d45e3c8db.

@gpaul

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2014

Comment 9:

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

@mewmew mewmew added fixed labels Jun 3, 2014

@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
[release-branch.go1.3] cmd/cgo: use same Go type for typedef to anony…
…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 added a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
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 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.
Projects
None yet
6 participants
You can’t perform that action at this time.