dlopen

问题 I was trying to install phonetisaurus . In the classical steps of configure, make, make install. I was stuck on make, where it produced this error. I have googled a lot, and many suggested appending -ldl at the back, but as you can see below, it's already there. make[3]: Entering directory `/opt/openfst-1.3.4/src/bin' g++ -DHAVE_CONFIG_H -I./../include -I./../script -g -O2 -MT fstarcsort.o -MD -MP -MF .deps/fstarcsort.Tpo -c -o fstarcsort.o fstarcsort.cc mv -f .deps/fstarcsort.Tpo .deps

问题 I am working on a project that uses MPI to create parallel processes, each process uses dlopen() to load a module that's been build as a shared object library. One of the modules that I'm writing uses a 3rd party library (HDF). When I run the program, dlopen throws an error: dlopen failed: /home/jwomble/QTProjects/SurrogateModule/libsurrogate.so: undefined symbol: H5T_NATIVE_INT32_g The undefined symbol is in the HDF library. How do I load the symbols from the HDF library? Currently, my make

问题 When same library is linked and used with dlopen, same function (sqrt in this example) has different memory addresses. Can you please explain why it is so? Is there some indirection? # cat dl-test.c #include <stdio.h> #include <stdlib.h> #include <dlfcn.h> #include <math.h> #include <inttypes.h> int main() { void *dl, *dl_sqrt; dl = dlopen("/lib/x86_64-linux-gnu/libm.so.6", RTLD_LAZY); if (!dl) { fprintf(stderr, "%s\n", dlerror()); exit(1); } dl_sqrt = dlsym(dl,"sqrt"); if (!dl_sqrt) {

问题 I'm trying to write a hook for stat / lstat / fstat but I can't seem to get the original version from dlsym . I'm using the following code to obtain the original pointers. orig_stat = dlsym(RTLD_NEXT, "stat"); orig_lstat = dlsym(RTLD_NEXT, "lstat"); orig_fstat = dlsym(RTLD_NEXT, "fstat"); However, all three variables are set to null and calling dlerror also returns null . I'm creating the shared object with: clang fakestat.c -shared -fPIC -ldl -o fakestat.so and using my library by running a

问题 I have a Linux application which loads in very small (a few small functions) shared libraries at run-time. For various Important Reasons™ I need the shared libraries to be loaded into a certain virtual memory range. However, dlopen() doesn't provide any means (that I can see) to tell it, or hint to it, where to put what it loads. Is there a way to tell dlopen() where it should put the library it loads? Is there some alternative to dlopen() which would provide that functionality? 回答1: I think

问题 When using the dlfcn family like so: #include <stdio.h> #include <dlfcn.h> typedef int(*timefunc_t)(void*); int main() { timefunc_t fun; void* handle; handle = dlopen("libc.so.6", RTLD_LAZY); fun = (timefunc_t)dlsym(handle, "time"); printf("time=%d\n", fun(NULL)); dlclose(handle); return 0; } It causes a Memory leak: ==28803== Memcheck, a memory error detector ==28803== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==28803== Using Valgrind-3.6.1 and LibVEX; rerun with -h for

问题 When using the dlfcn family like so: #include <stdio.h> #include <dlfcn.h> typedef int(*timefunc_t)(void*); int main() { timefunc_t fun; void* handle; handle = dlopen("libc.so.6", RTLD_LAZY); fun = (timefunc_t)dlsym(handle, "time"); printf("time=%d\n", fun(NULL)); dlclose(handle); return 0; } It causes a Memory leak: ==28803== Memcheck, a memory error detector ==28803== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==28803== Using Valgrind-3.6.1 and LibVEX; rerun with -h for

问题 I'm using dlsym() in C and I have a question whether the return value of dlsym() should be explicitly cast or if it is implicitly cast correctly. Here is the function: double (*(compile)(void))(double x, double y) { if (system("scan-build clang -fPIC -shared -g -Wall -Werror -pedantic " "-std=c11 -O0 -lm foo.c -o foo.so") != 0) { exit(EXIT_FAILURE); } void *handle; handle = dlopen("./foo.so", RTLD_LAZY); if (!handle) { printf("Failed to load foo.so: %s\n", dlerror()); exit(EXIT_FAILURE); }

问题 An error related to protobuf3 I have a project that have an c++ executable core, and several shared objects (.so, .dll) called plugins. When the core launches, it will load those plugins with dlopen. The core and plugins using protobuf as communication protocol, so they have to compile the generated .pb.cc and .ph.h files into their binaries to have the copy of the serializer/deserializer. And libprotobuf.so link to both the core and plugins. When I launch the core, it crushes with error:

问题 If a shared library (or a DLL) is being used through dlopen and dlclose mechanism and if the shared library created has some global variables whose memory comes from the heap, then what will happen to those variables and the memory when dlclose is called? If in the same process, dlopen is called again, what will be the behaviour? 回答1: If dlclose reduces the reference count to zero and the library is actually unloaded, any future reloading of the library should reset all variables with static