dlsym（RTLD_NEXT，“msgctl”）不返回默认版本

如果库定义了同一符号的多个版本，

dlsym（RTLD_NEXT，“symbol”）

返回旧符号，即使旧符号不是默认符号

例如，libpthread定义了pthread_cond_广播的两个版本：

$:> nm -g /lib64/libpthread-2.15.so|grep pthread_cond_broadcast
000000000000bfc0 T pthread_cond_broadcast@@GLIBC_2.3.2
000000000000c310 T pthread_cond_broadcast@GLIBC_2.2.5

• “GLIBC_2.3.2”是链接libpthread时获得的默认版本（没有任何dlsym参与）。（请注意表示默认符号的“@@”）
• “GLIBC_2.2.5”是一个较旧的版本

现在，如果我使用dlsym（RTLD_NEXT，“pthread_cond_broadcast”），我总是得到GLIBC_2.2.5版本，而不是GLIBC_2.3.2版本。当然，可以使用dlvsym获取默认版本，但是如果需要对大量符号执行此操作，并且其中许多符号具有不同的新/旧版本，则这会变得复杂

我知道RTLD_NEXT不应该总是返回最新的符号来保持兼容性，但是为什么不返回默认符号呢

---

有人知道这背后的原理吗？

下一步的整个要点是在第一个默认符号之后返回符号。您不只是在寻找

RTLD\u DEFAULT

？

据报道，这是一个glibc错误：

---

据我所知，它还没有被修复。

我只是遇到了以下问题：有一个指向：的指针，它描述dlsym总是返回旧的符号，而忽略默认的（@）版本。所以，我想，除非有人有任何建议，否则什么也做不了。我已经预装了一个库，在某些符号周围放置包装。为了调用libc版本，它使用dlsym（RDLD_NEXT，…）

dlsym

如果成功，则不调用

malloc

。当前的glibc实现使用

malloc

保存故障情况下

dlerror

的错误消息。使用

RTLD_NEXT

的插入式

malloc

可能会有一个回退分配器来处理此类重新分配问题。您必须检查实现情况或向

libc help

寻求建议。我不希望通常的

dladdr1

模式调用

malloc

，但可能有一些特殊模式可以调用。