qml.v1/cdata is not a valid package at tip (uses C code)

go-qml / qml

QML support for the Go language

Other

1.96k stars 187 forks source link

qml.v1/cdata is not a valid package at tip (uses C code) #106

Closed cookieo9 closed 10 years ago

cookieo9 commented 10 years ago

Compiling QML with the latest version of go at tip will fail with the following error:

package gopkg.in/qml.v1/cdata: C source files not allowed when not using cgo: cdata.c

A recent change to go https://code.google.com/p/go/source/detail?r=19aadfae8426d37d5ce6abf9d4e466daf118a647 has made all non-cgo C code outside the stdlib invalid and so the package can't be built.

I believe it is now expected to use assembly to do such tasks instead. Go 1.4 will likely ship with this restriction so this probably should be resolved soon.

niemeyer commented 10 years ago

Thanks for the report. I'll get that sorted.

cookieo9 commented 10 years ago

I have a partial solution here: https://github.com/cookieo9/qml/commit/882e3008e78677c5968c19dc6d95a2b984153a2b

It has the following problems/limitations:

The testing code seems to be broken (ie: cdata.Addrs() may not be implemented correctly)
The solution breaks go1.3 because it's heavily dependent on changes to the runtime, and there is no go1.4 tag yet to easily allow both solutions to exist at once.
It's been written to be portable using sample code from the stdlib, but I haven't tested it anywhere but on darwin/amd64

Otherwise, I was able to build some examples on my machine, and run them repeatedly without main-thread related errors (ie: cdata.Ref seemed to work correctly)

cookieo9 commented 10 years ago

Now that tip has introduced the go1.4 tag, I have an updated solution that works in 1.3 identically to before (it's the same code) dealing with the second issue. code: https://github.com/cookieo9/qml

I also updated the cdata.Addrs code for 1.4 and it seems to work (produce similar values to the go 1.3 code) but the qml tests still fail, this time at the panic at https://github.com/cookieo9/qml/blob/v1/testing.go#L68 . On a hunch I temporarily did what I could to get my new assembly to work in 1.3 and the tests did work, so it might be a case of the qml testing code not working in 1.4, as it's trying to binary patch the running executable's runtime.main function.

Should I initiate a pull request?

niemeyer commented 10 years ago

@cookieo9 Thanks for your help on this. The trick of the failure was a small modification in the test stub produced by "go test", but it was easy to fix. I wanted to go with pure assembly for all versions, but it was way too much trouble due to the lack of public header files for the basic things. In the end I gave up and followed your suggested approach of keeping the C files for the older releases, with mild differences in the implementation of Ref.