So, in python if I want to access an OSX bundle I can use the objc module like this:
import objc
objc.loadBundle('CoreWLAN',
bundle_path='/System/Library/Frameworks/CoreWLAN.framework',
module_globals=globals())
Is there an elegant way to do this in golang, perhaps with a module? Google is not finding me much. Do I have to call out to this using the C import features of the language? Is this even possible?
My specific situation is that I would like to read WIFI data for available access points, channels, signal strength and signal/noise ratio for talking to the Google Maps Geolocation API.
Andlabs gave an excellent response that he has unfortunately not put in as an answer.
Basically you use cgo like this...
//cgo LDFLAGS: -framework CoreWLAN
...and you are able to call into the framework directly. To quote his responses:
A .framework bundle contains at its top level a dynamically loaded library. In the case of the system frameworks, this dynamically loaded library's filename is the base name of the framework, and does not have the typical .dylib extension. If you are willing to use libdl directly, which means cgo, you can dynamically load this dylib and call its functions directly. But since we're using cgo at this point, there's a better way: //cgo LDFLAGS: -framework CoreWLAN and then use the API directly from cgo. – andlabs
And in fact, looking into it, CoreWLAN's API is Objective-C based, so you have no choice but to use cgo and do the latter of what I said :/ (Do not try to use the Objective-C runtime API directly; that leads to verbose, unsafe, and nonportable code.) – andlabs
Related
I have asked this question on linux, but now I need the same info on macos... The question is (adapted to macos):
I am trying to create a shared library, libbar.dylib, that embeds a commercial static library (licensing is fine). The commercial library has 4 versions: libfoo-seq.a, libfoo-mt.a, libfoo-seq.dylib, and libfoo-mt.dylib (they all provide the same symbols, just the code is sequential/multi-threaded, and the lib is static/shared). Of these four I want my code always to use the sequential foo library, so when I create libbar.dylib I link together my object files and libfoo-seq.a.
The problem is that the users of my library may have already pulled in libfoo-mt.dylib by the time they pull in my libbar.dylib, thus all symbols from libfoo are already present by the time libbar.dylib is read in, so my calls to the functions in foo are resolved to the multithreaded version. At least I think this is happening. Is there any way to double check?
If this is really what is happening, I wonder how can I resolve this issue? What kind of magic flags do I need to use when I compile to create my object files and when I link my object files with libfoo-seq.a to create libbar.dylib?
VPP provides the I/S for developing custom plugins that can be hooked into a graph of nodes. I've only seen examples for such plugins written in the C language, and was wondering whether other language, Go for instance, can also be used to write such plugins.
I have no idea what "VPP" is but nonetheless the answer is: "maybe"; here's why:
Go code is able to interface with C libraries via its facility known as cgo.
cgo is a multiple-faceted thing: it allows you to "export" certain Go functions in a certain way so that they can be called from the C side, and it allows you to call functions from the C side. It also allows you to write bits of inline C code to provide glue for the C side, when necessary.
Since some time Go building toolset (at least its "reference" implementation) provides for compiling Go code into a static or dynamic library with C-compatible API.
See this.
With these things in mind, in theory, it should be possible to do what you're after.
Note some possible obstacles:
Most of the time, if a "platform" allows you to write a "plugin" in C, it presupposes your plugin will make extensive use of the platform's own API.
This usually means your plugin is supposed to include certain header files provided by the platform.
The platform might also require your plugin to link against some platform-provided library (usually shared), or libraries.
cgo can do all of the above, but you will need to scrutinize the API provided by the platform and maybe write Go helpers to make its usage more natural for the Go code.
Building/linking issues (usually the locations of the header files and the libs) may also be a thing to solve.
I'm trying to build an old application that depends on fftw. It was written against fftw2 and I am currently on fftw3 (specifically 3.3.8). It fails to link because of undefined reference to fftw_create_plan and fftw_one. Indeed, my libfftw does not have those functions anymore; the following returns nothing:
readelf -s /usr/lib/libfftw3.so | grep 'fftw_create_plan\|fftw_one'
It looks like the api has changed significantly since the code was written. Is there a compatibility layer I can use or should I just go learn fftw3's new interface?
You cannot link an FFTW2 code against FFTW3 libraries, as you are coming to realize yourself. There is also no complete interface between the two, cause the apis are really not compatible.
Having said that, you may of course link your code against FFTW2 libraries. You still can obtain them. Why is that not an option?
How Will I import package dynamically and invoke its method in golang like java reflection package, there are solutions of how to invoke method in the same file using golang reflection but what about invoking from different package
What you're describing isn't dynamic package loading, it's just reflection. As long as the package is included in the binary and the types are exported, you can reference it the same way you can reference types in the same package.
Dynamic package loading is a different matter entirely; there's the new plugin support, which is still in its early stages, and not yet supported on all platforms. That's the closest you'll get.
Bear in mind that Go is not Java. Don't try to write Java in Go. It won't work. The platform, language, and standard library are very, very, very different between the two. Java can do dynamic class loading because it has a class loader. All types are dynamically loaded in Java. In Go, nothing is dynamically loaded; the Go compiler produces a native binary, there's nothing dynamic about it.
If you're trying to replicate something you're used to in Java, you're probably best served by rethinking your design entirely in a way that's more suitable to the technology you've chosen (Go), or to choose a technology more suited to the problem you're trying to solve.
I am accustomed to linking against libGL.so on most Linux distributions. Either mesa's implementation or NVIDIA's. However, I would really like to limit myself to OpenGL ES 2.X functionality, so I am attempting to link against and use libGLESv2.so. However, I see that glX functions are not present in libGLESv2.so dynamic section:
nm --dynamic /usr/lib64/nvidia/libGLESv2.so | grep glX
Also attempting to link agains libGLESv2.so results in undefined references to glX functions.
This leads me to my question. What is the correct way to "GetProcAddress" while dynamically linking against libGLESv2.so? Also how do you construct the appropriate context without glX?
I'm not sure how easy this will be for you to figure out and how relevant for your applications but in pi3d we get the drawing context using libEGL.so (or libegl.dll from ANGLE on windows).
This where the dynamic libraries are found and loaded
https://github.com/tipam/pi3d/blob/master/pi3d/constants/init.py
and this is where the surface is created and attached to the GLESv2 functions
https://github.com/tipam/pi3d/blob/master/pi3d/util/DisplayOpenGL.py