Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

remove dependency on cgo #109

Open
silbinarywolf opened this issue Sep 23, 2018 · 30 comments
Open

remove dependency on cgo #109

silbinarywolf opened this issue Sep 23, 2018 · 30 comments
Assignees
@hajimehoshi

Comments

@silbinarywolf
Copy link

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
Copy link
Member

how feasible is this?

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

@Noofbiz
Copy link

Noofbiz commented Sep 23, 2018

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
Copy link
Author

silbinarywolf commented Sep 24, 2018 •
edited
Loading

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 silbinarywolf mentioned this issue Sep 30, 2018
Open
@silbinarywolf
Copy link
Author

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

@jeff-emanuel
Copy link

jeff-emanuel commented Sep 30, 2018 via email

@hajimehoshi
Copy link
Member

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
Copy link
Member

DllImport

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

@hajimehoshi
Copy link
Member

hajimehoshi commented Oct 4, 2018 •
edited
Loading

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

@silbinarywolf
Copy link
Author

@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
Copy link
Member

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 hajimehoshi mentioned this issue Oct 20, 2018
Closed
@hajimehoshi
Copy link
Member

hajimehoshi commented Oct 20, 2018 •
edited
Loading

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
Copy link
Member

glfw/glfw#120 I got it, opengl32 is not enough.

@hajimehoshi
Copy link
Member

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
Copy link
Member

dmitshur commented Oct 21, 2018 •
edited
Loading

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
Copy link
Member

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

@hajimehoshi hajimehoshi mentioned this issue Oct 21, 2018
Closed
@hajimehoshi
Copy link
Member

hajimehoshi commented Oct 26, 2018 •
edited
Loading

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
Copy link
Member

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

@hajimehoshi hajimehoshi mentioned this issue Oct 27, 2018
Closed
@hajimehoshi
Copy link
Member

hajimehoshi commented Oct 27, 2018 •
edited
Loading

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
Copy link
Member

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

@hajimehoshi
Copy link
Member

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

@dmitshur
Copy link
Member

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.

@hajimehoshi hajimehoshi mentioned this issue Nov 12, 2018
Closed
@pwaller pwaller mentioned this issue Mar 30, 2019
Open
@neclepsio
Copy link

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

@MatejMagat305
Copy link

@neclepsio

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

Can I ask, when will it official?

hajimehoshi added a commit that referenced this issue Oct 25, 2021
@hajimehoshi
Update the Go version to 1.12
4174705 
At least, we will want syscall.Syscall18 for Windows in near future
to remove Cgo usages from Windows. 1.12 is the minimum version to
support this.

Updates #109
@hajimehoshi hajimehoshi mentioned this issue Oct 25, 2021
Merged
hajimehoshi added a commit that referenced this issue Oct 25, 2021
@hajimehoshi
Update the Go version to 1.12 (#144)
bda47ff 
At least, we will want syscall.Syscall18 for Windows in near future
to remove Cgo usages from Windows. 1.12 is the minimum version to
support this.

Updates #109
@Edouard127
Copy link

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
Copy link

Friedly ping

@MatejMagat305
Copy link

MatejMagat305 commented Feb 24, 2024 •
edited
Loading

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
Copy link

Seb-C commented Mar 20, 2024 •
edited
Loading

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
Copy link

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
Copy link

Seb-C commented Mar 20, 2024 •
edited
Loading

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
Copy link

ddkwork commented Aug 4, 2024

https://github.com/ddkwork/glfw

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hajimehoshi hajimehoshi

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Remove Cgo dependency on Windows hajimehoshi/glow
10 participants
@hajimehoshi @neclepsio @dmitshur @Seb-C @silbinarywolf @Noofbiz @ddkwork @jeff-emanuel @Edouard127 @MatejMagat305