Imagine that there is a shared library S, there are shared libraries A and B, and an executable C. A and B are linked against S. C is not linked against A and B, instead C dynamically loads A and B via dlopen. S has a static-storage-duration object O with external linkage that is used inside A and B. I
Tag: dlopen
Duplicate static variable initialization in C++
I build a shared library “libMyLibrary.so” with a class “MyClass” that contains a static variable of type “MyClass”. Then I build an executable “MyLibraryTest” that I link against “libMyLibrary.so”. The main program uses “dlopen” to load dynamically a “.so” given as an argument. While building, the library and executable are generated in a directory, say, “buildDir/bin”. Then I install the
linux dlopen : how to make loading lib manager
I have the same code compiled with different arch options (FMV does not work as the functions return sse and i can’t change “default” to something with sse) How can i make a meta-library that at load time checks the cpu capability and load the corresponding lib? (without any dlsym machinery)? Answer One way to achieve what you want is
dlopen fails in chroot
I’m attempting this: I have an environment defined in /chroot/debian6.0/ where I have bound some directories and created other ones. One is libs/ which contains the library libOne.so and its dependencies So: This library has been compiled in the chroot environment, and I want to open it with a process run from the containing environment. This is the code: remote.c
How to do runtime binding based on CPU capabilities on linux
Is it possible to have a linux library (e.g. “libloader.so”) load another library to resolve any external symbols? I’ve got a whole bunch of code that gets conditionally compiled for the SIMD level to be supported ( SSE2, AVX, AVX2 ). This works fine if the build platform is the same as the runtime platform. But it hinders reuse across
How to know if process has truly finished with a dlclose()ed library?
I’m on Linux (Ubuntu 12.04, gcc 4.6.3), trying to bend dlopen/close to my will in order to make a plugin-based application that can reload its plugins as and when necessary (e.g. if they’re recompiled). The basic theory is simple: dlopen the plugin; use it, keeping track of all its symbols that are in use. When the time comes to reload,