You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which leads me to think id type is similar to a void pointer.
When building the program below, I can tell that __OBJC__ is set. I can also tell id is declared even if I don't import <Cocoa/Cocoa.h>, because if I change the type from id to idx, I get a clang error:
./main.go:8:1: error: unknown type name 'idx'; did you mean 'id'?
idx foo() {
^~~
id
note: 'id' declared here
1 error generated.
Adding #import <Cocoa/Cocoa.h> or typedef void* id; does not make any difference on the error.
However, using a different type name (e.g., idx) and doing typedef void* idx; results in a successful compilation.
This issue might be related to #3505 which is the only remaining reported unresolved issue with a similar struct size calculation error error message.
mikioh
changed the title
cgo: "struct size calculation error" build error when returning id type from cgo to Go on Darwin.
cmd/cgo: "struct size calculation error" build error when returning id type from cgo to Go on Darwin.
Aug 7, 2015
The error means that the debug info shows that the debug info defines id as a struct that has size 0 but has an 8 byte field. That is clearly wrong. I can recreate the problem using clang/LLVM 3.4 on GNU/Linux (your test case works fine with GCC). Using readelf --debug on the object file generated by LLVM, I see this:
This says that id is a typedef for a pointer to the struct objc_object, and that objc_object has a size of 0 but has one member, isa, which is a pointer to the struct objc_class (the size of 0 can be seen at the line labeled 8e). So this debug info is incorrect: objc_object is 0 bytes but has a pointer field. The right fix would be to change LLVM to generate the correct debug info.
I can't think of a good way for cgo to handle this case. I think workarounds in the source code, as you suggest, is going to be your best bet. So I'm going to close this issue since it doesn't seem to be a problem we can fix in Go.
Standard Questions
What version of Go are you using (go version)?
What operating system and processor architecture are you using?
OS X Yosemite Version 10.10.4 (14E46)
What did you do?
Here's a small reproduce case. Create a
main.go
file in an empty folder:Then run:
What did you expect to see?
No output, because the build should be successful.
What did you see instead?
A failure to build, with the following error:
Notes
I'm not an expert on Objective-C, so this may be a user error. But from what I can tell, it looks like a longstanding bug with cgo.
Objective-C seems to have a predeclared type
id
. I have seen headers (in external code) that include the following:Which leads me to think
id
type is similar to a void pointer.When building the program below, I can tell that
__OBJC__
is set. I can also tellid
is declared even if I don't import<Cocoa/Cocoa.h>
, because if I change the type fromid
toidx
, I get aclang
error:Adding
#import <Cocoa/Cocoa.h>
ortypedef void* id;
does not make any difference on the error.However, using a different type name (e.g.,
idx
) and doingtypedef void* idx;
results in a successful compilation.This issue might be related to #3505 which is the only remaining reported unresolved issue with a similar
struct size calculation error
error message.Original issue is go-gl/glfw#136.
The text was updated successfully, but these errors were encountered: