cmd/cgo: mysterious missing typedef[...] definition on Mac OS X handling internal Objective-C types #8238
Labels
Comments
jrick (the conformal/gotk3 guy) seems to think this is a clang-specific problem. (I wouldn't be surprised...) [11:30] <jrick> andlabs: I think issue #8238 is related to clang, when I build go 1.3 with gcc, cgo doesn't panic (but I get other weirdness with *C.T and *C.struct__T errors) [11:32] <jrick> what's even more odd is that the *C.struct__T errors don't seem deterministic [11:32] <jrick> i.e. run go get once, and the build fails [11:33] <jrick> run it again, and everything works :/ [11:33] <jrick> I wonder if my glib/gtk packages are built with clang That being said, I can try both comments's requests on OS X later (and then remember how to use GNUstep for a Linux-based example). |
"Try changing that line to do nothing if there is no entry in the typedef map and see
what happens."
No panic; everything seems to compile and run fine.
Minimal test:
package main
// #cgo LDFLAGS: -framework Foundation -lobjc
// #include <objc/message.h>
// #include <objc/objc.h>
// #include <objc/runtime.h>
import "C"
func main() { var x C.id; println(x) }
Can't reproduce on Linux; compilation works fine but fails during link due to
incompatible linker options in the LDFLAGS above.
pietro@pietro-laptop:/tmp$ gcc --version
gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
pietro@pietro-laptop:/tmp$ clang --version
Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: x86_64-pc-linux-gnu
Thread model: posix
|
I've been able to build gotk3 using a clang-built go tip several times now with no panics or other issues (that also includes the missing typedef issues from issue #8463). |
Sounds like this was fixed--please reopen if not. Status changed to Duplicate. Merged into issue #8368. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
from src/cmd/cgo/gcc.go: 1286 if isStructUnionClass(sub.Go) { 1287 // Use the typedef name for C code. 1288 typedef[sub.Go.(*ast.Ident).Name].C = t.C 1289 } When handling one of Objective-C's internal types, go get github.com/andlabs/ui fails with a nil pointer dereference panic at line 1288 above. Upon further investigation: ### sub.Go:&ast.Ident{NamePos:0, Name:"_Ctype_struct_objc_object", Obj:(*ast.Object)(nil)} sub.Go.(*ast.Ident):&ast.Ident{NamePos:0, Name:"_Ctype_struct_objc_object", Obj:(*ast.Object)(nil)} ....Name:"_Ctype_struct_objc_object" typedef:map[string]*main.Type{"_Ctype_struct_objc_cache":(*main.Type)(0x2083eacc0), "_Ctype_int":(*main.Type)(0x2084d7480), "_Ctype_struct_objc_method_list":(*main.Type)(0x2084d7e00), "_Ctype_SEL":(*main.Type)(0x2084d7b00), "_Ctype_Class":(*main.Type)(0x2084d7040), "_Ctype_long":(*main.Type)(0x2084d7280), "_Ctype_struct_objc_ivar":(*main.Type)(0x2084d7700), "_Ctype_Method":(*main.Type)(0x2083eac00), "_Ctype_struct_objc_selector":(*main.Type)(0x2084d7a80), "_Ctype_IMP":(*main.Type)(0x2084d7cc0), "_Ctype_struct_objc_method":(*main.Type)(0x2084d7d80), "_Ctype_uint":(*main.Type)(0x2084d7f80), "_Ctype_Protocol":(*main.Type)(0x2083eb000), "_Ctype_char":(*main.Type)(0x2084d71c0), "_Ctype_struct_objc_ivar_list":(*main.Type)(0x2084d7780)} t:&main.Type{Size:8, Align:-1, C:(*main.TypeRepr)(0x2084f66f0), Go:(*ast.Ident)(0x2084e53c0), EnumValues:map[string]int64(nil), Typedef:""} t.C:&main.TypeRepr{Repr:"Protocol", FormatArgs:[]interface {}(nil)} ### expr:(*main.Type)(nil) so while all the parts of the typedef[...] line are valid, the typedef[...] expression itself is not. I'm not sure what's going on here. I'm running Mac OS X 10.8 with go version go version devel +f39dff1bf0d4 Thu Jun 19 22:18:24 2014 +1000 darwin/amd64 and clang version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin12.5.0 Thread model: posix but people at andlabs/ui#9 have different setups. Thanks!The text was updated successfully, but these errors were encountered: