Add Go 1.3 support

[dom3k]

After compiling, i am getting the error:

github.com/conformal/gotk3/glib ../../../../github.com/conformal/gotk3/glib/glib.go:327: cannot use idleSrc (type C.GSource) as type C.structGSource in argument to sourceAttach ../../../../github.com/conformal/gotk3/glib/glib.go:350: cannot use timeoutSrc (type C.GSource) as type C.structGSource in argument to sourceAttach ../../../../github.com/conformal/gotk3/glib/glib.go:361: cannot use src (type C.struct__GSource) as type C.GSource in argument to _Cfunc_g_source_destroy ../../../../github.com/conformal/gotk3/glib/glib.go:387: cannot use src (type C.struct__GSource) as type C.GSource in argument to _Cfunc_g_source_destroy ../../../../github.com/conformal/gotk3/glib/glib.go:394: cannot use src (type C.struct__GSource) as type C.GSource in argument to _Cfunc_g_source_set_closure ../../../../github.com/conformal/gotk3/glib/glib.go:398: cannot use src (type C.struct__GSource) as type C.GSource in argument to _Cfunc_g_source_attach ../../../../github.com/conformal/gotk3/glib/glib.go:724: cannot use glist (type C.struct__GList) as type C.GList in argument to _Cfunc_g_list_append ../../../../github.com/conformal/gotk3/glib/glib.go:724: cannot use _Cfunc_g_list_append(glist, C.gpointer(data)) (type C.GList) as type C.structGList in assignment ../../../../github.com/conformal/gotk3/glib/glib.go:731: cannot use glist (type *C.structGList) as type C.GList in argument to _Cfunc_g_list_prepend ../../../../github.com/conformal/gotk3/glib/glib.go:731: cannot use _Cfunc_g_list_prepend(glist, C.gpointer(data)) (type C.GList) as type *C.struct__GList in assignment ../../../../github.com/conformal/gotk3/glib/glib.go:731: too many errors

go vet: glib.go:1043: possible misuse of unsafe.Pointer glib.go:1048: possible misuse of unsafe.Pointer glib.go:1053: possible misuse of unsafe.Pointer glib.go:1058: possible misuse of unsafe.Pointer glib.go:1063: possible misuse of unsafe.Pointer glib.go:1068: possible misuse of unsafe.Pointer glib.go:1073: possible misuse of unsafe.Pointer glib.go:1078: possible misuse of unsafe.Pointer glib.go:1083: possible misuse of unsafe.Pointer glib.go:1088: possible misuse of unsafe.Pointer glib.go:1093: possible misuse of unsafe.Pointer glib.go:1098: possible misuse of unsafe.Pointer glib.go:1103: possible misuse of unsafe.Pointer glib.go:1108: possible misuse of unsafe.Pointer glib.go:1113: possible misuse of unsafe.Pointer glib.go:1118: possible misuse of unsafe.Pointer glib.go:1123: possible misuse of unsafe.Pointer

http://golang.org/doc/go1.3 Changes to the garbage collector

For a while now, the garbage collector has been precise when examining values in the heap; the Go 1.3 release adds equivalent precision to values on the stack. This means that a non-pointer Go value such as an integer will never be mistaken for a pointer and prevent unused memory from being reclaimed.

Starting with Go 1.3, the runtime assumes that values with pointer type contain pointers and other values do not. This assumption is fundamental to the precise behavior of both stack expansion and garbage collection. Programs that use package unsafe to store integers in pointer-typed values are illegal and will crash if the runtime detects the behavior. Programs that use package unsafe to store pointers in integer-typed values are also illegal but more difficult to diagnose during execution. Because the pointers are hidden from the runtime, a stack expansion or garbage collection may reclaim the memory they point at, creating dangling pointers.

Updating: Code that uses unsafe.Pointer to convert an integer-typed value held in memory into a pointer is illegal and must be rewritten. Such code can be identified by go vet.

Best regards

[jrick]

I'll look into this soon, but I have been running go tip for quite some time now without any issues (the C.struct_ strictness must have been a recent change?). I'm not quite sure yet what fallout there will be for the changes to the GC, but my first impressions are that gotk3 code is still legal. It does not store arbitrary values, or pointers to cgo objects, in Go pointer types (uintptr aside), and the go vet warnings are all for unsafe.Pointer -> uinptr -> unsafe.Pointer type conversions, where the pointer is to a cgo object, so the GC should leave it alone.

[jrick]

It may also be a compiler bug, but with the latest Go built from the release-branch.go1.3 branch, I do see the compile errors for the C.struct_ strictness, but on a second 'go get', it compiles and installs without error.

[jrick]

I don't like blaming this on compiler bugs, but I'm not sure what else it could be. Even after explicitly converting types with unsafe to a C.T, when passing the variable to a function that takes a C.T, go build complains that I can't use C.struct__T as a type for a function that takes a C.T.

[jrick]

Can you confirm some details about your system? I assume that you are using a Go built with gcc (otherwise I believe cgo should be panicking due to this: https://code.google.com/p/go/issues/detail?id=8238). Also, do you know if your installed glib/gtk was built with clang or gcc?

I am running an slightly old Bitrig snap, but I believe my glib/gtk packages are built with clang. It would be good to know if this is a problem with gcc-compiled Go and clang-compiled glib, and whether gcc Go and gcc glib work as expected.

[dom3k]

Hello, thank you for your response. After reinstalling gotk3, i get these errors:

sudo -E go get -tags gtk_3_10 github.com/conformal/gotk3/gtk github.com/conformal/gotk3/glib goPaczki/src/github.com/conformal/gotk3/glib/glib.go:724: cannot use glist (type C.struct__GList) as type C.GList in argument to _Cfunc_g_list_append goPaczki/src/github.com/conformal/gotk3/glib/glib.go:724: cannot use _Cfunc_g_list_append(glist, C.gpointer(data)) (type C.GList) as type C.structGList in assignment goPaczki/src/github.com/conformal/gotk3/glib/glib.go:731: cannot use glist (type *C.structGList) as type C.GList in argument to _Cfunc_g_list_prepend goPaczki/src/github.com/conformal/gotk3/glib/glib.go:731: cannot use _Cfunc_g_list_prepend(glist, C.gpointer(data)) (type C.GList) as type C.struct__GList in assignment goPaczki/src/github.com/conformal/gotk3/glib/glib.go:738: cannot use glist (type C.structGList) as type C.GList in argument to _Cfunc_g_list_insert goPaczki/src/github.com/conformal/gotk3/glib/glib.go:738: cannot use _Cfunc_g_list_insert(glist, C.gpointer(data), C.gint(position)) (type C.GList) as type *C.structGList in assignment

goPaczki is my GOPATH. I'm using Ubuntu 14.04 64bit. My version of GTK is 3.10, GTK is probably compiled using gcc. GCC version 4.8.2. With go 1.2, it worked fine.

Best regards.

[GeertJohan]

From the go1.3 release notes (http://golang.org/doc/go1.3#cgo):

The cmd/cgo command, which processes import "C" declarations in Go packages, has corrected a serious bug that may cause some packages to stop compiling. Previously, all pointers to incomplete struct types translated to the Go type *[0]byte, with the effect that the Go compiler could not diagnose passing one kind of struct pointer to a function expecting another. Go 1.3 corrects this mistake by translating each different incomplete struct to a different named type.

Given the C declaration typedef struct S T for an incomplete struct S, some Go code used this bug to refer to the types C.struct_S and C.T interchangeably. Cgo now explicitly allows this use, even for completed struct types. However, some Go code also used this bug to pass (for example) a *C.FILE from one package to another. This is not legal and no longer works: in general Go packages should avoid exposing C types and names in their APIs.

Updating: Code confusing pointers to incomplete types or passing them across package boundaries will no longer compile and must be rewritten. If the conversion is correct and must be preserved, use an explicit conversion via unsafe.Pointer.

[GeertJohan]

It's probably not related to my comment on 23 jun. I didn't read the errors correctly.

It looks like it's related to this: https://code.google.com/p/go/issues/detail?id=8463

[jrick]

Go 1.3.1 is released now, which has the needed cgo fixes to build gotk3 again.