Native Darwin Support

[tapir]

Due to a bug in cgo we commented out https://github.com/go-gl/glfw/blob/master/v3.1/glfw/native_darwin.go (See Issue #82)

Unfortunately I don't have a mac, can we test if this is still an issue?

[dmitshur]

I can test this.

[dmitshur]

Uncommenting those 2 funcs, I still get:

glfw $ go version
go version go1.4.2 darwin/amd64
glfw $ go build
# github.com/go-gl/glfw/v3.1/glfw
./native_darwin.go:12:9: struct size calculation error off=8 bytesize=0

[dmitshur]

golang/go#7555 is still not resolved.

[dmitshur]

golang/go#7555 is now closed, so this might be fixed in Go 1.5. I'll try again then, unless someone can test it sooner.

[dmitshur]

Well, this doesn't look good. Despite golang/go#7555 being resolved by now, it doesn't appear to fix this issue. I just tried with go1.5beta3.

$ go install github.com/go-gl/glfw/v3.1/glfw
# github.com/go-gl/glfw/v3.1/glfw
github.com/go-gl/glfw/v3.1/glfw/native_darwin.go:10:9: struct size calculation error off=8 bytesize=0
$ go version
go version go1.5beta3 darwin/amd64

@slimsag, we should make sure that this issue is indeed related to golang/go#7555 and not something else. Does it mean golang/go#7555 is not truly resolved? If so, there's little time before 1.5 comes out, so this may end up being postponed to Go 1.6 which is 6+ months down the line. Luckily, this issue is not very critical, but it will be nice to resolve it eventually.

[dmitshur]

It's surprising that the GLFW v3.0 bindings have nearly the same code in the github.com/go-gl/glfw/v3.0/glfw/native_darwin.go file and yet that seems to compile okay. What makes v3.1 different?

[dmitshur]

Well, after looking into details of golang/go#7555 and the messages that pointed to it, I realize it's a completely unrelated issue to this problem.

golang/go#7555 was referred to by @slimsag in response to #82 (comment), which mentions an undefined: strdup error.

This struct size calculation error is unrelated to golang/go#7555 so it's no wonder that issue being resolved did not fix this issue.

[tapir]

On a side note, since golang/go#7555 is now closed can we revert back #87 once 1.5 is out?

[dmitshur]

Sure, but please make a separate issue for that.

I'll try to make a small reproducible sample for this struct size calculation error so we can create a specific Go issue if needed.

[dmitshur]

This issue might be related to golang/go#3505 which is still unresolved.

All other issues that contain that error message appear to be resolved.

[dmitshur]

Here's a really short reproduce case:

// +build darwin

package main

/*
#cgo CFLAGS: -x objective-c

id foo() {
    return 0;
}
*/
import "C"

import "fmt"

func main() {
    fmt.Println(C.foo())
}

Building that results in:

./main.go:17:14: struct size calculation error off=8 bytesize=0

[tapir]

A lot of the cgo libraries out there should fail to compile if this is
really the case. Are you opening an issue in golang ?
On 6 Aug 2015 11:23, "Dmitri Shuralyov" [email protected] wrote:

Here's a really short reproduce case:

// +build darwin
package main
/#cgo CFLAGS: -x objective-cid foo() { return 0;}/import "C"
import "fmt"
func main() {
fmt.Println(C.foo())
}

Building that results in:

./main.go:17:14: struct size calculation error off=8 bytesize=0

—
Reply to this email directly or view it on GitHub
#136 (comment).

[emidoots]

Nice job tracking this down @shurcooL! Apologies for not being very responsive here prior.

I tried looking into it a bit now but it is hard to tell if it's related to golang/go#3505 or not. I agree with @tapir about opening a new issue for it so it is not overlooked.

[dmitshur]

I've filed a new issue with all the details at golang/go#12065.

[tapir]

Looks like the problem lies within LLVM

[james4k]

Can we return a uintptr instead? What do you gain from using C.id in the exported API?

[dmitshur]

That could work. I think C.id was used because that's the type that the C API returns.

Have you tried it with uintptr?

[james4k]

Using cgo types in an exported API is a little weird since AFAIK cgo types in each package are distinct. C.id from a package that may use this API is a different type from glfw's C.id.

[tapir]

I'm ok with using a reference to it instead of the actual C type.

[dmitshur]

@james4k, would you be able to make a PR that resolves this issue?

[james4k]

Sure. What I ended up needing to do was a little more involved, where the conversion is done on the C side with a wrapper inline function that returns void *.

[emidoots]

James, that sounds correct. Not sure how else it could be worked around.
On Aug 28, 2015 7:59 PM, "James Gray" [email protected] wrote:

Sure. What I ended up needing to do was a little more involved, where the
conversion is done on the C side with a wrapper inline function that
returns void *.

—
Reply to this email directly or view it on GitHub
#136 (comment).

[Zijun-Yin]

Due to a bug in cgo we commented out https://github.com/go-gl/glfw/blob/master/v3.1/glfw/native_darwin.go (See Issue #82)

Unfortunately I don't have a mac, can we test if this is still an issue?

When I ues fyne on MacOS12 with gcc11, I found it a bug which make fyne bad!

# github.com/go-gl/glfw/v3.3/glfw
In file included from /Users/pro/go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/native_darwin.go:7:
In file included from ./glfw/include/GLFW/glfw3native.h:95:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12: