dlopen

问题 I was trying the issue mentioned at link: https://sourceware.org/ml/libc-alpha/2009-06/msg00168.html I did some modification in the code as mentioned below: >> Cat libdep.c #include <stdio.h> int duplicate = 'u'; int get_duplicate() { printf("libdep sees duplicate as: %c\n", duplicate); printf("libdep sees duplicate address as: %x\n", &duplicate); return duplicate; } -------------------------------------------------------------------------------------- >> Cat dynamic.c #include <stdio.h>

问题 I figure out I can have the implementation of parts of a class in a shared lib, as far as the symbols are loaded when used. myclass.h --- class C { void method(); } main.cpp --- #include "myclass.h" int main() { //dynamically load mylib.so using dlopen/dlsym/dlclose ... C *c = new C(); c->method(); delete c; } mylib.so compiled separately: ==== mylib.cpp --- #include "mylib.h" void C::method() { ... } This works fine. However once I finished using C::method(), I would like to unload it, so I

问题 I am toying around with c++17 and plugins, and I have run into an error that I cannot get around. In the following MWE I can call a local function that takes a std::any , and everything works as expected when I try to read the contents. When I load this exact same function through a plugin (dlopen), it correctly sees the type on the any, but it cannot std::any_cast the contents. Any help would be greatly appreciated in figuring out what is causing this error. Here is my environment, MWE, and

问题 In a main program, I dlopen and dlclose ( LoadLibrary and FreeLibrary respectively) a shared library. The shared library contains a static variable that is instantiated upon dlopen , and destroyed upon dlclose . This behavior is consistent on MSVC 2008 and 2013, GCC 3.4.6, and Sunstudio 12.1. With GCC 4.9.1 and GCC 5.2.1 however, the destructor was no longer called on dlclose . Instead, it was called before program exit. The particularity of the static variable's class, is that in the

问题 I have a linux shared library, foo.so, which is loaded from an executable using dlopen("foo.so", RTLD_NOW | RTLD_LOCAL) . From foo.so I'd like to dlopen another library, bar.so, which references symbols defined in foo.so, but the linker fails to find them. I can't change RTLD_LOCAL to RTLD_GLOBAL, because I don't have the source to the executable doing the loading. I thought -Wl,--export-dynamic when linking foo.so might help but it doesn't override the local flag to dlopen. GCC's new

问题 I have to dynamic load .so in Linux, but I find it is difficult to deal with the same name libraries. I have 2 libtest.so in different directories and they are depend on other different libraries. My program read config file to decide to load which libtest.so. For example: /usr/kyle/v1/libtest.so /usr/kyle/v2/libtest.so They are all not registered in ldconfig. So how can I load different version of libtest.so using dlopen? I hope that they will not be conflict with each other, because they

问题 I'm writing a proxy class that loads a shared library with dlopen() and forwards its member functions to the appropriate members of the proxied class instance inside the loaded shared object behind the scenes. For example, the shared object has a Person class: class Person { ... void setName(std::string name); }; I've added a wrapper file that includes the person.h header and defines the following symbol: extern "C" { void Person_setName(void* instancePointer, std::string name); } This call

问题 I have started using valgrind just one day ago as suggested by someone on SO itself .Its an amazing tool but today i got an issue with it.It gives the following error : definitely lost bytes but unable to tell the location of error. Here is the output of valgrind : udit@udit-Dabba ~ $ valgrind --leak-check=full sendip -v -p ipv6 -f file.txt -6s ::1 -p ah -as 0x20 -aq 0x40 -ak "yugal" -am xorauth.so -p udp -us 21 - ud 21 ::2 ==12885== Memcheck, a memory error detector ==12885== Copyright (C)

问题 Good evening, I'm currently working on a Plugin system in C++/Linux based on the Plux.net model. To keep it simple, I basicly declare a symbol (lets call it pluginInformation) with extern C (to unmangle) and my plugin manager look for that symbol in the pre configured imports (.so). The thing is that the main application declares the same symbol, not only that but any dependency it have may have the symbol aswell. (since in this pluginInformation, modules can publish plugs and/or slots). So

问题 Let's say I have an libA.so with GCC constructor. My program "program" depends on libA.so, so when I run it, libA.so gets opened and its constructor is executed. Now, I also have a module, libC.so, which also depends on libA. I run dlopen("libC.so") , which loads libC, and according to my experiments, also executes libA's constructor . Dependencies look like this: libA has the constructor libB also has a constructor libC depends on libA and libB program depends on libA program links libC via