Go 1.6 cgo incompatibility

[Joakim Lundborg]

Hi,

It seems go-qml is broken in Go 1.6 (as already reported in https://github.com/go-qml/qml/issues/170). I would very much like to be able to run my app without ugly GODEBUG=cgocheck=0

I am especially concerned by this because of the lack of updates and merges of outstanding PR:s, it would be unfortunate if important bugs like this would not be corrected.

Does anyone know how hard it would be to fix this? I am willing to help sorting this out, but my experience in cgo/go is a bit limited so I don't know where to start.

Best regards,

-- Joakim

[Gustavo Niemeyer]

Hi Joakim,

The issue is indeed known, as the changes coming into cgo of 1.6 were discussed well in advance.

It's doable technically, as any constraint of the type "cannot have Go pointer" can always be replaced by a map key (say, an uintptr) to a Go pointer that is held in Go memory, passing the key to C++ space instead of the pointer itself. So the GC is happy, as it can move or do whatever else it pleases with the real Go pointer, and go-qml is happy as it can hand out keys into C++ space that won't change behind its back.

I will definitely look at those issues once a window shows up, but the upcoming list of critical projects in the next couple of months is a bit daunting, so I'm sorry for not being able to make short term promises.

I wish we had more developers engaged into the development of the project, but it seems like there are way too many less-than-half-baked Go GUI projects in the wild splitting the attention of Go developers.

 

--
You received this message because you are subscribed to the Google Groups "go-qml" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-qml+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

gustavo @ http://niemeyer.net

[Ignazio Di Napoli]

Hi Gustavo.

I took all the definition in capi.h which take pointers, then looked in *.go for matches.

I got the following result:

C.componentCreate

C.componentCreateWindow

C.componentErrorString

C.componentLoadURL

C.componentSetData

C.contextGetProperty

C.contextSetObject

C.contextSetProperty

C.contextSpawn

C.delImage

C.delObject

C.delObjectLater

C.delString

C.engineAddImageProvider

C.engineRootContext

C.engineSetContextForObject

C.engineSetOwnershipCPP

C.engineSetOwnershipJS

C.goValueActivate

C.idleTimerInit

C.imageBits

C.imageConstBits

C.imageSize

C.newComponent

C.newEngine

C.newGoValue

C.newListProperty

C.newString

C.newVariantList

C.objectConnect

C.objectFindChild

C.objectGetProperty

C.objectGoAddr

C.objectInvoke

C.objectIsComponent

C.objectSetProperty

C.objectTypeName

C.registerResourceData

C.registerSingleton

C.registerType

C.unregisterResourceData

C.windowConnectHidden

C.windowGrabWindow

C.windowHide

C.windowPlatformId

C.windowRootObject

C.windowShow

 

So, I think this is the complete list of what needs to be changed.

Now, if you gave me an example of how you want to do it, I could try to do it.

Thank you.

[Gustavo Niemeyer]

Thanks Ignazio.. I'll try to find some time over the next days to have a deeper look into this issue.

[Steve Beaulac]

Looking into the codes, It looks like hookGaValueTypeNew and wrapGoValue go function in bridge.go both create a valueFold values and send the value's pointer to cgo. cgo store this value, causing the error message. 

On line bridge.go:238 a fold pointer is passed to C.newGoValue

On line bridge.go:305 a fold pointer is return from the hookGoValueTypeNew.

So if I understand what Gustavo wrote. I would store each fold value in a map, and pass the key instead of a pointer. 

SjB

[Joakim Lundborg]

Hi,

I have had some success building with the WIP branch by Steve Beulac https://github.com/SjB/qml/tree/go1.6-port. 

An example of using this in a vendor tree is here:

https://github.com/cortex/gopass (based on my private go-qml branch with some additional patches)

With this, my application  builds and runs just fine with Go 1.6

-- Joakim