使用 libtool 从共享库中加载重复的函数名 [英] Using libtool to load a duplicate function name from a shared library

问题描述

我正在尝试创建一个调试"共享库(即 .so 或 .dll 文件)，它调用另一个与调试库具有相同 C API 的真实"共享库(在这种情况下，模拟PKCS#11 API).但是，我遇到了调试库的链接映射与真实库的链接映射发生冲突并导致调试库调用自己的函数而不是真实库中的相应函数的麻烦.我通过使用 POSIX dlmopen 命令找到了解决此问题的方法，但想了解是否可以使用 GNU 的 libtool.

I'm trying to create a 'debug' shared library (i.e., .so or .dll file) that calls another 'real' shared library that has the same C API as the debug library (in this case, to emulate the PKCS#11 API). However, I'm running into trouble where the link map of the debug library is colliding with that of the real library and causing the debug library to call its own functions instead of the corresponding functions in the real library. I found a solution to this problem by using the POSIX dlmopen command, but would like to understand if the same is possible using GNU's libtool.

在我的 Solaris 10 系统上，当测试应用程序静态链接到调试库时，以下代码无法断言:

On my Solaris 10 system, the following code fails the assertion when a test application statically links to the debug library:

#include <dlfcn.h>
int MyFunctionName() {
  int (*function_ptr)();
  void *handle = dlopen("realsharedlibrary.so", RTDL_LAZY);
  *(void **)(&function_ptr) = dlsym(handle, "MyFunctionName");
  ASSERT(function_ptr != MyFunctionName); // Fails
  return (*function_ptr)();
}

在这种情况下，我得到一个指向本地MyFunctionName"(在调试库中)的函数指针，而不是真正共享库中的 MyFunctionName.

In this case, I get a function pointer to the local 'MyFunctionName' (in the debug library) instead of MyFunctionName within the real shared library.

我发现可以通过使用命令dlmopen"而不是dlopen"来解决这个问题，并告诉 dlmopen 创建一个新的链接映射(使用 LM_ID_NEWLM 参数)加载真实库时:

I've discovered that it's possible to get around this problem by using the command 'dlmopen' instead of 'dlopen', and telling dlmopen to create a new link map (with the LM_ID_NEWLM parameter) when loading the real library:

int MyFunctionName() {
  int (*function_ptr)();
  void *handle = dlmopen(LM_ID_NEWLM, "realsharedlibrary.so", RTDL_LAZY);
  *(void **)(&function_ptr) = dlsym(handle, "MyFunctionName");
  ASSERT(function_ptr != MyFunctionName); // succeeds
  return function_ptr(); // call real function
}

不幸的是，dlmopen 似乎没有包含在 libtool 中(即，我在 libtool 中没有看到 lt_dlmopen 函数).

Unfortunately, dlmopen does not seem to be included within libtool (i.e., I don't see an lt_dlmopen function in libtool).

是否可以使用 libtool 命令来做同样的事情——也就是说，在加载新库时创建一个新的链接映射，这样它就不会与调试库的链接映射发生冲突?

Is it possible to do the same thing using libtool commands -- that is, to create a new link map when loading the new library so that it doesn't collide with the link map of the debug library?

推荐答案

我还没有找到使用 libtool 来解决这个问题的好方法，但是有一种方法可以通过使用来避免 Solaris 特定的 'dlmopen' 函数dlopen 带有这些标志:

I haven't found a good way to use libtool to solve this problem yet, but there's a way to avoid the Solaris-specific 'dlmopen' function by using dlopen with these flags:

void *handle = dlopen("realsharedlibrary.so", RTLD_NOW | RTLD_GROUP | RTLD_LOCAL)

显然，使用RTLD_NOW代替RTLD_LAZY并添加RTLD_GROUP解决了符号冲突的问题.RTLD_LOCAL 存在是因为 POSIX 需要使用 RTLD_LOCAL 或 RTLD_GLOBAL，否则行为未定义.对于 Solaris，行为默认为 RTLD_LOCAL.

Apparently, the problem of symbol-collisions is solved by using RTLD_NOW instead of RTLD_LAZY and by adding RTLD_GROUP. The RTLD_LOCAL is there because POSIX requires using either RTLD_LOCAL or RTLD_GLOBAL, or the behavior is undefined. For Solaris, the behavior is to default to RTLD_LOCAL.

不过，悬而未决的问题是是否可以将这些类型的标志传递给 lt_dlopen.

The open question, though, is whether it's possible to pass these types of flags to lt_dlopen.

这篇关于使用 libtool 从共享库中加载重复的函数名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！