search

hajimehoshi / ebiten

Ebitengine - A dead simple 2D game engine for Go
https://ebitengine.org
Apache License 2.0
10.52k stars 641 forks source link

remove cgo on macOS (darwin) #1162

Open hajimehoshi opened 4 years ago

hajimehoshi commented 4 years ago

https://groups.google.com/forum/m/#!topic/golang-nuts/Wt6P0BYndvs

mortenson commented 4 years ago

Would this enable cross compilation, i.e. compiling mac binaries from linux?

hajimehoshi commented 4 years ago

Yes, theoretically :-)

hajimehoshi commented 3 years ago

Another nice reference CL: https://go-review.googlesource.com/c/go/+/227037/

hajimehoshi commented 3 years ago

As M1 appears, might this be in higher demand than before?

hajimehoshi commented 3 years ago

Hmm, GLFW is the toughest blocker so far.

hajimehoshi commented 3 years ago

https://github.com/progrium/macdriver sounds reasonable!

EDIT: Probably this doesn't work with Arm yet

hajimehoshi commented 2 years ago

I want to prioritize this, as it is now impossible to build amd64 version from M1 macOS.

hajimehoshi commented 2 years ago

Hm, we should be able to use environment variables CC, CFLAGS or something for other architectures.

EDIT: Just CGO_ENABLED=1 was enough!

hajimehoshi commented 2 years ago

https://developer.apple.com/documentation/objectivec/objective-c_runtime?language=objc

TotallyGamerJet commented 2 years ago

https://gist.github.com/vaiorabbit/6204931#file-building-libglfw-dylib-on-macos-apple-silicon

This explains how to build glfw as a dylib which can then by dynamically linked to using dlopen and dlsym.

hajimehoshi commented 2 years ago

Oops, I used a wrong issue number for the recent commits.

aprchen commented 2 years ago

I want to prioritize this, as it is now impossible to build amd64 version from M1 macOS.

Is it can be compiled in version 2.4 ?

hajimehoshi commented 2 years ago

Is it can be compiled in version 2.4 ?

Hopefully yes

TotallyGamerJet commented 1 year ago

In my Ebitengine branch glfw-purego I Dlopen glfw as a Dylib. It is fully functional. I am trying to figure out the best way to distribute the dylib. When you did the dll for windows you copied it to the cache and opened it there. On macOS the traditional place to put dylib is in the .app inside some kind of Frameworks folder. Requiring users of Ebitengine to do that would not be backwards compatible bc some users use the direct executable and don’t use a .app. Perhaps write the file in a Frameworks folder no matter where the executable is located that way if it is in a .app it’ll be write and users can do externaldylib if they want to do it themselves and save space. Lmk what you think

TotallyGamerJet commented 1 year ago

Also when you did the dll you wrote a ten.go to get the dll. I used the script linked above to compile the dylib. Should I write a generator in Go as well?

TotallyGamerJet commented 1 year ago

According to This post Apple will reject apps that don’t wrap .dylib in a .framework? Can we find an official source to validate this? Edit: Apple Docs

hajimehoshi commented 1 year ago

Hi, thank you for continuing this work!

Can we map the constent of the dysym and load it dynamically? (On Windows it was not possible and I had to extract a DLL as a file)

Should I write a generator in Go as well?

Yes!

hajimehoshi commented 1 year ago

Another way is to translate GLFW to Go like what I did for Windows (https://github.com/hajimehoshi/ebiten/tree/main/internal/glfwwin)

TotallyGamerJet commented 1 year ago

Even with the parts that are the same that would be a lot to code especially since there are quite a few Objective-C classes that would all have to be ported. I was planning on working on that port after everything else with moved to purego but there doesn’t appear to be an easy way Dlopen/Dlsym a file from memory.

if I go the porting route should I just modify glfwwin package since there are constants and types that are shared?

hajimehoshi commented 1 year ago

if I go the porting route should I just modify glfwwin package since there are constants and types that are shared?

Yes. I'm totally fine with renaming from glfwwin to, for example, goglfw. I keep the file structure as the original as much as possible so I hope it is easy to add code for macOS.

TotallyGamerJet commented 1 year ago

Another problem with porting glfw right now is that there are quite a few objective c functions that return structs which SyscallN does not support. I was planning on writing a more general calling mechanism that could support returning and taking structs although it would be slower than SyscallN

hajimehoshi commented 1 year ago

Acknowledged. I don't think the overhead of SyscallN matters so much, and I'm fine with slowing a little. Thank you for your hard work!

hajimehoshi commented 1 year ago

I removed iOS from the title since iOS build must require Cgo for c-archive.

hajimehoshi commented 1 year ago

As Go 1.20 will come soon, we would not make it for Ebitengine v2.5. I'll set the milestone to v2.6.

hajimehoshi commented 12 months ago

https://github.com/ebitengine/purego/issues/143 is the current blocker.

hajimehoshi commented 11 months ago

There can be a trouble around Xcode versions: https://wails.io/docs/guides/troubleshooting/#my-mac-app-gives-me-weird-compilation-errors

So, removing Cgo is very beneficial :D

hajimehoshi commented 6 months ago

As I'm pretty busy with other tasks, I have not been able to work on this recently 😢 . I think https://github.com/ebitengine/purego/pull/175 could be a possible blocker, but is this actually? @TotallyGamerJet

TotallyGamerJet commented 6 months ago

It is a blocker for completion since there are a few C functions in glfw that return or take structs. The majority of it can be completed. Plus, struct Args PR is ready for review