GCC / LD Связывание искаженных символов, не распознаваемых JNA - PullRequest
Новая
       9

GCC / LD Связывание искаженных символов, не распознаваемых JNA

0 голосов
/ 29 ноября 2018

Нечетный вопрос здесь не совсем уверен, как его задать.

Я пишу некоторые привязки JNA для проприетарной разделяемой библиотеки.

API библиотеки имеет несколько функций, называемых такими вещами, как km_open, km_closeи т. д. В 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);

, что является приемлемым обходным путем. Я просто хочу понять, что происходит здесь в фоновом режиме.

1 Ответ

0 голосов
/ 29 ноября 2018

Не берите в голову, я нашел ответ, это было довольно сложно, но вместо того, чтобы ссылаться на сам файл библиотеки .so, make-файл генерировал фрагмент объектного кода с тем же именем, что и библиотека .so, которая определяла методы-оболочки, которыединамически загружаются функции "c_".затем они связываются с этим фрагментом объектного кода вместо библиотеки.он не появился в поиске, потому что это был сгенерированный файл.Решение в JNA состоит в том, чтобы просто имитировать это поведение, создавая класс-оболочку с упрощенными именами, которые делают обратный вызов для привязок JNA

...