我有一个二进制库和一个使用该库的二进制可执行文件，两者都是用C编写的。我知道该库提供的C API，但既没有库的源文件也没有可执行文件。我想了解可执行文件如何使用该库（比较我之前的问题How to know which functions of a library get called by a program）。
建议的解决方案未给出令人满意的结果。似乎没有提到的可能性似乎是实现一个包装器库，该包装器库模仿我感兴趣的二进制库的已知接口。我的想法是将对包装器的所有调用转发到二进制库。这应该允许我记录所有调用和传递的参数，换句话说，是对库进行检测。
我成功地在Linux上将包装器库实现为动态链接库（* .so），并将我自己的示例应用程序连接到包装器。包装器依次使用原始二进制库。这两个库都与dlopen和dlsym一起使用以访问API。但是，我面临以下实际问题：我无法将原始二进制可执行文件链接到包装器库。这与可执行文件期望使用特定名称的库有关。但是，如果我以这种方式命名我的说唱歌手库，那么它将与原始库冲突。令人惊讶的是（对我而言）仅重命名该.so文件并将其链接到包装库是行不通的（当包装库调用dlopen时，结果停止并且没有错误消息，并且我没有从中获取更多信息调试器，而不是发生在malloc中。）
我尝试了很多方法，例如使用符号链接将其中一个库移出运行时链接程序的搜索路径，将路径添加到LD_LIBRARY_PATH环境变量中，而这些变量的位置相对不同。这样的文件（以及dlopen的相应路径）以及不同的编译器选项，到目前为止都没有成功。
总而言之，我想
(executable)_orig->(lib.so)->(lib.so)_orig
其中(executable)_orig和(lib.so)_orig（我无法影响的二进制文件）是如此
(executable)_orig->(lib.so)_orig
有效。我有(lib.so)的来源，可以根据需要对其进行修改。另外，我可以根据需要修改Linux主机系统。 (lib.so)的任务是告诉我(executable)_orig和(lib.so)_orig如何相互作用。
我也有
(executable)->(wrapper.so)->(lib.so)_orig
正在工作，这似乎表明该问题与库的命名和加载约定有关。
这是一个单独的新问题，因为它处理了上面概述的特定实际问题。除此之外，一些有关为何重命名与(lib.so)_orig相对应的文件以解决该问题可能失败的背景信息也可能会有用。