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.
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
Unify support for dlopen/LoadLibrary/.. #38825
Comments
It's not a simple problem. What language is your shared library written in? If it's written in C, or any language that uses a C-compatible API, then you will have to call any shared library functions via cgo. The plugin package only works with shared libraries that are written in Go. Methods like Go is an open source project. If you want to propose a approach to this general problem, I encourage you to do so. There are many subtleties. You may want to look at https://golang.org/s/execmodes to get a start on the problem space. Thanks. |
Hello Ian, Out of the box I got a working .so (or .dll on Windows). -- What language is your shared library written in? What is confusing to me is that I cannot write a Yes there could be struct alignment problems and on Win In Java one can use JNA: Ruby has a ffi interface: (Lua was a bad example, because it currently does not Maybe I miss something, but the other discussions I have Best regards |
Go also has a FFI interface: cgo. It seems to me that you are suggesting that Go have a way to call into shared libraries written in C without using cgo. That won't work. As I said above, if the shared library is written in C, or any language that uses a C-compatible API, then you will have to call any shared library functions via cgo. |
-- That won't work. -- Go also has a FFI interface: cgo. From the JNA Website: Three major languages have the feature, but it seems that Go got stuck in the C world. |
I think what you're asking is for Go to implicitly wrap a member of a shared library when it's requested, which is what cgo does at compile time. (Note that Java & Ruby are not compiled languages.) That might not be too hard if the function signature only has primitive types and no pointers. Structs and pointers would complicate matters. There haven't been many requests for this (I don't think), so making it happen probably requires a volunteer with relevant experience. |
Java is a compiled language and has/had to solve the same technical issues. The funny thing is that the plugin interface |
Fair enough, the Windows code hides some of the cgo approach from the user. It still uses the cgo mechanisms underneath, and it provides a limited list of types, so it has limited flexibility. Yes, using cgo requires a limited amount of C knowledge. I personally don't consider that to be a problem. If you are calling C code from Go code you need to understand C memory management. I don't see cgo as comparable to JNI. Using JNI requires writing different kinds of code in C. That is not true of cgo. You can use cgo exactly like the Windows syscall API by writing only C If someone wants to make a detailed proposal for how to simplify cgo, perhaps to work likely the syscall WIndows API, go ahead. We can consider that. |
That doesn't seem to have happened, so I'm closing this issue for now. |
It would be nice to finally have some cross platform support
for loading shared objects, without the need for cgo (and complex tool chains).
The syscall package has support for
LoadLibrary and
GetProcAddress
and the plugin package has support for
dlopen and
dlsym
Why there is still no package with cross
platform suppport?
I have a shared object with 150 entry points
compiled with _cdecl / x64 and I can load and use it
cross platform in LUA and COBOL but
not with GO (without a complex cgo toolchain).
Best regards
The text was updated successfully, but these errors were encountered: