remove dependency on cgo

[silbinarywolf]

How much effort is this or how feasible is this? It'd be great if I didn't need to install additional build tools on my Windows machines when working with this library. It would also make cross-compilation from Windows to Linux easier.

I'd be willing to put in the work if someone is able to point to examples of other repositories that removed the dependency on cgo.

[dmitshur]

how feasible is this?

I don't know of a way of doing this. If someone knows a way, please share.

[Noofbiz]

I honestly don't think this would be possible. OpenGL itself is an API for graphics and the interface is all written in C, so you don't have to know (proprietary) things about the graphics card and driver. Even if you did reverse engineer your own card and figure out what memory addresses and what needs to be written there to perform what, it would work specifically for your card and driver. You'd have to do it all over again for every graphics card / driver setup out there. That's exactly the problem OpenGL was created to solve. Another issue would be whether or not Go could actually do this since it's got a GC. It would require a lot of working around that to get it functional.

[silbinarywolf]

I'd imagine a solution like c2goasm, where we have a tool to auto-generate Go assembly versions of each of the OpenGL functions.

c2goasm: https://github.com/minio/c2goasm Article: https://blog.minio.io/c2goasm-c-to-go-assembly-bb723d2f777f

[silbinarywolf]

Another potential solution is using this too: https://github.com/elliotchance/c2go

[jeff-emanuel]

That's not relevant. You need Go code to call a C API. You can't convert the opengl implementation to Go. (I guess technically you could, but you'd then have a dog slow software implementation. )

On Sun, Sep 30, 2018, 2:19 AM Jake Bentvelzen notifications@github.com wrote:

Another potential solution is using this too: https://github.com/elliotchance/c2go

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/go-gl/gl/issues/109#issuecomment-425703634, or mute the thread https://github.com/notifications/unsubscribe-auth/AhhKJwvW76gqHgMSBC8uikgGIckgSFNJks5ugH51gaJpZM4W1mHp .

[hajimehoshi]

This is possible at least on Windows by DllImport, and this should be worth trying since it is hard to install gcc in Windows compared to other Posix OSes like macOS or Linux.

[hajimehoshi]

DllImport

I meant NewLazyDLL. For example, I could call WinMM functions without cgo: https://github.com/hajimehoshi/oto/blob/master/winmm_windows.go

[hajimehoshi]

@silbinarywolf I was wondering if you are working on this. If not, can I do this (for Windows)?

[silbinarywolf]

@hajimehoshi I haven't started anything and I've only toyed with a few of the c2go libraries to see how they work. So go ahead and do this :)

[hajimehoshi]

I realized this is important to improve even go get time: Now it takes very long time to go get -u github.com/go-gl/gl on Windows.

[hajimehoshi]

Question: now on Windows, wglGetProcAddress is used when available. Would it be fine to always use LazyDLL("opengl32") and its NewProc? Will they cause different results?

[hajimehoshi]

https://github.com/glfw/glfw/issues/120 I got it, opengl32 is not enough.

[hajimehoshi]

https://godoc.org/github.com/go-gl/gl/v2.1/gl#BufferStorageExternalEXT

Oops, there are APIs that exposes C types. This means that we'll break backward compatibility if we eliminate dependencies on Cgo :-/

[dmitshur]

Indeed. However, there's only 8 of them (compared to hundreds or thousands of Go types), and I don't think they should've been exposed in the first place. I don't know whether they're functional (it might not be possible to use them).

According to https://golang.org/cmd/cgo/, "a Go package should not expose C types in its exported API":

Cgo translates C types into equivalent unexported Go types. Because the translations are unexported, a Go package should not expose C types in its exported API: a C type used in one Go package is different from the same C type used in another.

[hajimehoshi]

I confirmed these functions are not used (at least on GitHub). I'm now writing proposal to replace these types :-)

[hajimehoshi]

I think I've done 80%: https://github.com/hajimehoshi/glow/tree/nocgo

Probably I'll be able to send a PR this week end :-)

[hajimehoshi]

The current problem is that func LGPUCopyImageSubDataNVX has so many arguments that syscall.SyscallN cannot accept :-/

[hajimehoshi]

Hi,

I wrote the proposal https://docs.google.com/document/d/1mqquznil9fR2amtb3eTC2ObCx3A8Af_5INqKjO-pKDg/edit?usp=sharing how to eliminate Cgo usages on Windows. Feedbacks are welcome!

Before starting to review the PR, I'd like to confirm that we agree the direction. Thanks!

[hajimehoshi]

Hi, what's going on this? (@dmitshur ?)

[hajimehoshi]

That is unfortunate, but if we couldn't reach agreement, I'd need to make a fork of go-gl...

[dmitshur]

I think we did reach agreement. We talked on slack and I left some comments on the proposal document. As long as you're willing to help maintain the Windows cgo-free version, we're happy to accept it.

[neclepsio]

In the meantime it gets merged, you can use my fork.

[MatejMagat305]

@neclepsio

In the meantime it gets merged, you can use my fork. it work perfeckly

Can I ask, when will it official?

[Edouard127]

This absolutely needs to be merged, I literally can't build anything on Windows and this fixed my issue

In the meantime it gets merged, you can use my fork.

[MatejMagat305]

Friedly ping

[MatejMagat305]

In the meantime it gets merged, you can use my fork.

Wait, wasn`t it pull request? If the problem is not pull request, I will look to this ... or is it need fix also glfw?

[Seb-C]

Has anyone made an attempt using this? https://github.com/petermattis/fastcgo

All of my calls to OpenGL are inside an OS-locked thread, so my understanding is that the drawbacks would not be an issue.

[MatejMagat305]

Has anyone made an attempt using this? https://github.com/petermattis/fastcgo

All of my calls to OpenGL are inside an OS-locked thread, so my understanding is that the drawbacks would not be an issue.

fastcgo is unsafe and use cgo, this is thread obout remove them similar https://github.com/ebitengine/purego

[Seb-C]

Has anyone made an attempt using this? https://github.com/petermattis/fastcgo All of my calls to OpenGL are inside an OS-locked thread, so my understanding is that the drawbacks would not be an issue.

fastcgo is unsafe and use cgo, this is thread obout remove them similar https://github.com/ebitengine/purego

Oh, you are correct, sorry about this. I confused this thread for a discussion about the performance overhead of cgo, while this one is more about the build process.

[ddkwork]

https://github.com/ddkwork/glfw