dlopen

How to circumvent dlopen() caching?

由 …衆ロ難τιáo~ 提交于 2021-01-28 06:08:27
问题 According to its man page, dlopen() will not load the same library twice: If the same shared object is loaded again with dlopen(), the same object handle is returned. The dynamic linker maintains reference counts for object handles, so a dynamically loaded shared object is not deallocated until dlclose() has been called on it as many times as dlopen() has succeeded on it. Any initialization returns (see below) are called just once. However, a subsequent dlopen() call that loads the same

Loading executable or executing a library

由 戏子无情 提交于 2020-12-06 12:25:06
问题 There is a large number of questions on SO about how to execute a library or dynamically load an executable. As far as I can tell, all the answers come down to: compile your executable as position-independent code and load it with dlopen . This worked great --- and still works great on macOS --- until a recent change in glibc, which explicitly disabled dlopen ing PIEs. This change is now in the current version of glibc (2.30) on ArchLinux, for example, and trying to dlopen a position

Loading executable or executing a library

由 丶灬走出姿态 提交于 2020-11-29 09:29:05
问题 There is a large number of questions on SO about how to execute a library or dynamically load an executable. As far as I can tell, all the answers come down to: compile your executable as position-independent code and load it with dlopen . This worked great --- and still works great on macOS --- until a recent change in glibc, which explicitly disabled dlopen ing PIEs. This change is now in the current version of glibc (2.30) on ArchLinux, for example, and trying to dlopen a position

using std::thread in a library loaded with dlopen leads to a sigsev

由 家住魔仙堡 提交于 2020-07-15 04:42:09
问题 I recently discovered a strange behaviour using std::thread and dlopen . Basically, when I execute a std::thread in a library which is loaded using dlopen I receive a sigsev. The library itself is linked against pthread, the executable that calls dlopen is not. Once I link the executable against pthread or the library itself everything works fine. However, we are using a plugin based infrastructure, where we do not know if the application itself is linked against pthread or not. Therefore, it

dlopen works second time on bad shared library on ubuntu 11.04; does the right thing on centos 5.5

由 大憨熊 提交于 2020-06-27 05:03:28
问题 I have bad shared library (undefined symbol). When I call dlopen() on it the first time, I get a NULL result with correct error message from dlerror(). If I ignore the error message and call dlopen() using the same arguments, I get a non-null handle the second time (which indicates that the library was successfully loaded). This is obviously wrong. This problem occurs under Ubuntu 11.04 (IIRC, 10.10 did not have this problem). Centos 5.5 doesn't exhibit this problem. In particular, this

Resolving dynamic libraries dependencies when loading with dlopen()

由 橙三吉。 提交于 2020-05-29 07:20:30
问题 I faced a problem with loading a dynamic library with dlopen() : I attempt to load a library: handle = dlopen("libmkl_intel_lp64.so", RTLD_LAZY); This code fails with the following message from dlerror() : /opt/intel/composer_xe_2013_sp1.2.144/mkl/lib/intel64/libmkl_intel_lp64.so: undefined symbol: mkl_vsl_serv_threader_for I know that this symbol can be found in another library, libmkl_gnu_thread.so for example. If use LD_PRELOAD to load that library the above mentioned error on undefined

Resolving dynamic libraries dependencies when loading with dlopen()

由 余生长醉 提交于 2020-05-29 07:19:51
问题 I faced a problem with loading a dynamic library with dlopen() : I attempt to load a library: handle = dlopen("libmkl_intel_lp64.so", RTLD_LAZY); This code fails with the following message from dlerror() : /opt/intel/composer_xe_2013_sp1.2.144/mkl/lib/intel64/libmkl_intel_lp64.so: undefined symbol: mkl_vsl_serv_threader_for I know that this symbol can be found in another library, libmkl_gnu_thread.so for example. If use LD_PRELOAD to load that library the above mentioned error on undefined

dlopen failed: library "/system/lib/libxxx.so" needed or dlopened by "/system/lib/libnativeloader.so

由 旧时模样 提交于 2020-03-17 11:52:20
Android 加载so库:dlopen failed: library “/system/lib/libSpiDevice.so” needed or dlopened by “/system/lib/libnativeloader.so” is not accessible for the namespace “classloader-namespace” 简易说明我的解决方法,不代表一定可以解决. 1.将需要调用的libSpiDevice.so放到/system/lib下, 2.运行程序发现报错,百度一查说是要把改so库的名字写到/system/etc/public.libraries.txt,这个文件里 3,adb pull出来,修改,adb push进去,重启; 重点来了:将libSpiDevice.so加到public.libraries.txt这个文件时,注意要换行,换行,换行!!!,否则push到系统中是识别不到的,cat public.libraries.txt,会发现根本没有刚添加的字段…这就是没有换行.所以,记得换行,换行,换行. 来源： CSDN 作者： 车水码农 链接： https://blog.csdn.net/qq_35390092/article/details/104859765

lib和so

由 雨燕双飞 提交于 2020-02-28 06:32:05
静态库，是中间产物。 动态库，是最终产物。 静态库，是声明完整的。 动态库，是声明定义完整的。 动态库 windows: 可以通过加载和dlopen的方式使用 linux:可以通过dlopen的形式使用。 来源： oschina 链接： https://my.oschina.net/u/3695598/blog/3159432

Referencing global symbols from shared library loaded with dlopen

由 坚强是说给别人听的谎言 提交于 2020-02-15 18:01:54
问题 I have a shared library which I want to access symbols from the main program. For example: main.c #include <stdio.h> void bar(void) { puts("bar"); } extern void foo(void); int main(void) { foo(); return 0; } foo.c #include <stdio.h> extern void bar(void); void foo(void) { puts("foo"); bar(); } I compile and run like: gcc -c -fpic foo.c gcc -shared -o libfoo.so foo.o gcc -L$(pwd) -o test main.c -lfoo ./test And I get the output I expect: foo bar However, I must use dlopen() and dlsym() because
订阅 dlopen