GCC/LD链接JNA未识别的损坏符号

Question

这里的奇怪问题不太确定如何提问。

我正在为一个专有的共享库编写一些JNA绑定。

库api有几个名为kmopen、kmclose等的函数。在c中，这些函数在头文件中定义如下：

Komodo km_open (
int port_number
);
int km_close (
Komodo komodo
);

在Java中，我为它们创建了JNA绑定，定义如下：

public abstract Komodo km_open(int port_number);
public abstract int km_close(Komodo komodo);

但是JNA未能在库中找到这些符号。当我转储二进制文件中的符号时我发现以下内容：

0000000000008e20 g    DF .text  0000000000000005  Base        net_km_open
0000000000007410 g    DF .text  0000000000000005  Base        c_km_open
0000000000008e40 g    DF .text  0000000000000005  Base        net_km_close
0000000000007430 g    DF .text  0000000000000005  Base        c_km_close

我猜测，因为这个库是由.net和独立的c应用程序使用的，所以这些名称被篡改以提供该函数的替代版本。然而，我在演示应用程序的源代码中找不到任何将名称c_km_open映射到km_open的内容。然而，它在GCC中编译，代码也能正常工作。当链接/加载二进制文件时，这些符号是如何解析的？JNA有做同样事情的方法吗？目前，如果我这样修改绑定，我可以让JNA绑定工作：

public abstract Komodo c_km_open(int port_number);
public abstract int c_km_close(Komodo komodo);

这是一个可以接受的变通方法，我只想了解这里的背景情况。

Answer 1

无论如何，我找到了答案，这有点棘手，但makefile没有链接到.so库文件本身，而是生成了一段与.so库同名的对象代码，该库定义了动态加载"c_"函数的包装方法。然后，它们链接到该段目标代码，而不是库。它没有出现在搜索中，因为它是一个生成的文件。JNA中的解决方案是通过创建一个具有简化名称的包装器类来简单地模仿这种行为，该包装器类对JNA绑定进行回调