Linker ctype加载的共享库符号也在glibc中定义；如何选择符号？

使用python ctypes；加载的共享库（a）定义了一个

sem_init

函数，该函数由链接到库a的后续加载的共享库（B）调用。执行（在gdb中）会导致分段错误，看起来库B从

/lib/libpthread.so.0

调用

sem_init@@GLIBC_2.4

（GLIBC的一部分？）而不是库A提供的

sem\u init

为了确认，我在库A和B中重命名了

sem_init

，问题就消失了。不幸的是，其他程序依赖于库A中的符号

sem_init

，因此这不是一个解决方案。如何确保库B在不更改库A的情况下从库A调用

sem_init

不幸的是，其他程序依赖于库A中的符号sem_init，因此这不是一个解决方案

从

libB

到

sem_init

的引用解析为

libpthread.so.0

（GLIBC的一部分）中的定义，因为

libpthread.so.0

作为主

python

二进制文件的依赖项加载，因此在符号搜索列表中出现在

libA

之前。因此，对

sem_init

的每个“正常”引用都将解析为

libpthread

s定义。这是按预期工作的（覆盖标准库提供的符号是一个非常糟糕的主意（TM））

通过在

libB

中执行类似操作，可以强制

libB.so

使用

libA.so:sem_init

（省略错误检查）：

---

如果

sem_init

是唯一冲突的符号，这将起作用，但如果存在其他符号冲突，则可能以不明显的方式中断。

使用什么命令行来构建这两个库？

void *h = dlopen("libA.so", RTLD_NOW|RTLD_GLOBAL)
void (*p_sem_init)(...) = dlsym(h, "sem_init");

// Call it:
p_sem_init(...);