dlopen

问题 Currently I'm creating some sort of plugin system. My program writes the code, which is then compiled (see also my other question). The resulting (compiled) library is than opened again using dlopen . This allows people to program custom functions in the program themselves. //Open the compiled library at the specified path void* handle = dlopen("COMPILEDLIBRARYPATH", RTLD_LAZY); if (handle == NULL) { std::cout << "plugin not found" << std::endl; } //Find the function pointer and cast is to

问题 I have a working program that loads plugins with dlopen . New requirement: at some point in the code, I'm given a pointer, and I need to test whether this pointer points into the code or static data of a plugin. bool is_pointer_into_plugin(void *p, void *handle); Equivalently, I need to retrieve the plugin into which a pointer points, if any. I also need to know if the pointer points into the main program's code or static data (and ideally, distinguish between read-only and read-write areas).

问题 I want to load the same .so file twice as separate instances. Based on the example, I have created the app with two dlopen commands. However, I was facing some issues and I understood that dlmopen should be used if I am using multiple instances of a same .so . However, I don't know how to pass the arguments. Can someone help me how to do this in GFortran? My code is as below, program example use :: iso_c_binding implicit none integer(c_int), parameter :: rtld_lazy=1 ! value extracte from the

问题 I have this small testcode atfork_demo.c : #include <stdio.h> #include <pthread.h> void hello_from_fork_prepare() { printf("Hello from atfork prepare.\n"); fflush(stdout); } void register_hello_from_fork_prepare() { pthread_atfork(&hello_from_fork_prepare, 0, 0); } Now, I compile it in two different ways: gcc -shared -fPIC atfork_demo.c -o atfork_demo1.so gcc -shared -fPIC atfork_demo.c -o atfork_demo2.so -lpthread My demo main atfork_demo_main.c is this: #include <dlfcn.h> #include <stdio.h>

问题 I would like to use cffi (or even ctypes if I must) to access a C ABI from Python 3 on Linux. The API is implemented by a number of .so files (let's call them libA.so , libB.so and libC.so ), such that libA contains the main exported functions, and the other libs provide support for libA . Now, libA depends on libB and libB depends on libC . However, there's a problem. There's a global array defined by libA that libC expects to be present. So libC actually depends on libA - a circular

问题 I am trying to build a native library for an Android application. I have 2 libraries and I need to link them in my final library, but I have some problems. The Android.mk code: LOCAL_CFLAGS := -Wall -Wfloat-equal -std=c99 LOCAL_PATH := $(call my-dir)/.. include $(CLEAR_VARS) LOCAL_MODULE := cpu-lib LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/cpu/inc LOCAL_EXPORT_CPPFLAGS := $(LOCAL_CFLAGS) LOCAL_EXPORT_LDLIBS := -llog LOCAL_SRC_FILES := $(LOCAL_PATH)/cpu/lib/$(TARGET_ARCH_ABI)/libdemoDSP.so

问题 The C++11 Standard states, § 3.6.2, 4: "It is implementation-defined whether the dynamic initialization of a non-local variable with static storage duration is done before the first statement of main." The C++ Standard distinguishes static initializations, which requires only evaluation of compile time constants, from dynamic initialization. I believe the observable effects of eager static initialization are guaranteed. I'm interested in eager initialization in any case. Given that this

问题 I have an issue when I try to use dlopen() to load a shared library into another shared library. I checked all tutorials on how to use dlopen() correctly. So here is the simplified code: The main shared library contains a class with pure virtual functions which the sub-shared library (aka plug-in) must implement. Additionally, it has some other functions which are implemented with a default behavior. I created a macro which is added to every plug-in to have a symbol to load and create the

问题 What if I want these externals to be resolved in runtime with dlopen? Im trying to understand why including an h file, with shared library external vars and funcs, to a C executable program results in undefined/unresolved. (when linking) Why do I have to add "-lsomelib" flag to the gcc linkage if I only want these symbols to be resolved in runtime. What does the link time linker need these deffinitions resolutions for. Why cant it wait for the resolution in runtime when using dlopen. Can

问题 I have a shared object (a.so) which is linked to my executable myexe. a.so exposed a method called get_val(), which myexe is using. Now when a.so will be loaded into myexe's process address space? is it when myexe calls get_val() API, or when myexe gets launched. 回答1: There are two (three) types of libraries: static libraries (suffix: .a / .lib ), which itself becomes part of the binary. Strictly speaking, it's not the whole library, it's those objects from the library which are required to