I've introduced Boost.Container into my project which uses jemalloc as default allocator, looks like Boots.Container uses custom allocator which is dlmalloc and of course when linking I'm failing on "multiple definition" linkage error since two "XXXalloc" were introduced into object files. Turning the 'jemalloc' off is not an option but I cant find if it is possible to turn off the dlmalloc usage. Any idea how to solve this problem?
In reality, Boost Container is 99% header-only.
The documentation lists the DLMalloc extension as an extension: https://www.boost.org/doc/libs/1_73_0/doc/html/container/extended_allocators.html
This means you have apparently opted in to the extended allocator. If that's not what you wanted, you know what to remove.
A good hint is when you don't need to link Boost Container, as a quick inspection of the symbols exported didn't show me anything I recognize except allocator stuff.
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?
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?
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
I have a program do so some graphics. When I run it interactively, I want it to use OpenGL from the system to provide hardware accelerated graphics. When I run it in batch, I want to be able to redirect it to use the Mesa GL library so that I can use OSMesa functionality to render to an offscreen buffer. The OSMesa functionality is enabled by doing a LoadLibrary/GetProcAddress if the batch start up option is selected.
On Linux, its fairly easy to make this work. By using a wrapper script to invoke the program, I can do something like this:
if [ "$OPTION" = "batch" ]; then
export LD_LIBRARY_PATH=$PATHTO/mesalibs:$LD_LIBRARY_PATH
fi
It is possible to do something this in Windows?
When I try adding a directory to the PATH variable, the program continues to go to the system opengl32.dll. The only way I can get the program to use the Mesa GL/OSMesa shared libraries is to have them reside in the same directory as my program. However, when I do that, the program will never use the system opengl32.dll.
If I've understood what you're saying correctly, the wrong version of opengl32.dll is being loaded when your process starts up, i.e., load-time dynamic linking. There is probably no good way to solve your problem without changing this.
You say you can't use conveniently use run-time dynamic linking (LoadLibrary/GetProcAddress) for opengl32.dll because the calls to it are coming from the Qt library. I presume that the Qt library is itself dynamically linked, however, so you should be able to solve your problem by using run-time linking for it. In this scenario, provided you load opengl32.dll before you load the Qt library, you should be able to explicitly choose which version of opengl32.dll you want to load.
You might want to consider using delayed loading in order to simplify the process of moving from load-time to run-time linking. In this scenario, the first call into the Qt library causes it to be loaded automatically, and you'll just need to explicitly load opengl32.dll first.
There are a few ways you could handle this, depending on the libraries and their names/locations:
If both have the same name (opengl32.dll), then you need to add the Mesa DLL location to the search path such that it is searched before the system directory. The order directories are checked in is detailed here. As you can see, $PATH comes last, after system, so you can't just add the directory to that. However, you can make use of the second step ("The current directory") by setting the working directory to a path containing the mesa files. Generally this means starting the application using an absolute path while in the directory containing the files.
That's still not particularly pleasant, though. If you can, you should use LoadLibrary and check for an environment variable (OPENGL_LIBRARY_PATH) when your app starts up. Assuming the exports from opengl32.dll and Mesa's DLL are the same, you can do something like:
void LoadExports()
{
char location[MAX_PATH];
getenv("OPENGL_LIBRARY_PATH", location);
HMODULE oglLib = LoadLibrary(location);
function1 = GetProcAddress(oglLib, "glVertex2f");
...
}
This will work perfectly fine, doing almost exactly what you want.
However, if you want to do that, you can't import opengl32.dll, which you're probably doing, you have to dynamically link throughout. Make sure not to link against opengl32.lib and you should be fine. Depending on how many functions you use, it may be a pain to set up, but the code can easily be scripted and only needs done once, you can also use static variables to cache the results for the lifetime of the program. It's also possible to use different function names for different libraries, although that takes a bit more logic, so I'll leave the details to you.
Though this should be possible in the cmd window, it seems you're having no luck.
Try: set a variable in your script (RUNNING_IN_SCRIPT=Y) and then parse for that variable in your executable and LoadLibrary from the absolute path of installation - be sure to clear the variable when you exit.
Windows used to search different paths for dynamic libraries, but due to security consideration, the system path is searched first.
You could, however use Delay Load Imports to get a workaround:
If you're using MSVC, you could single-out the DLLs you're interested in loading on your own with /DELAYIMPORT flag to the linker.
Then, override the delay load helper function and use LoadLibrary to find the proper DLL (and not trust it to the system).
After loading the correct DLL, have your helper function just call the original one that will do all the GetProcAddress business by itself.