LINUX.ORG.RU

uClibc и HASP


0

0

Потребовалось запустить hasp на uClibc. Бинарник драйвера (aksusbd) динамически скомпонован с glibc, пример использования API статически компонуется с бинарными библиотеками, которые тоже имеют ссылки на функции glibc, которых нет в uClibc. Я имею очень смутные понятия о программировании и ковырялся следующим образом.
ldd aksusbd
libpthread.so.0 => /lib/libpthread.so.0
libc.so.6 => not found
libc.so.0 => /lib/libc.so.0
/lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0
Нет libc.so.6, делаю ссылку libc.so.6=>libc.so.0. Пытаюсь запустить:
./aksusbd: No such file or directory.
Ладно, копаю дальше, лезу в aksusbd, нахожу там /lib/ld-linux.so.2, ага, нет линковщика, делаю ссылку /lib/ld-linux.so.2=>ld-uClibc.so.0.
Пытаюсь запустить -
./aksusbd: can't resolve symbol '__libc_start_main' in lib './aksusbd'.
Копаюсь в исходниках uClibc, похоже, что аналогичная функция - __uClibc_main. Правлю бинарник (меняю __libc_start_main на __uClibc_main). Опять пытаюсь запустить:
./aksusbd: can't resolve symbol '__register_frame_info' in lib './aksusbd'.
Ищу, что за __register_frame_info, оказывается в libgcc.a. Собираю библиотечку c этой функцией:
gcc -shared -Wl,-soname,libc.so.6 -o libc.so.6 -u__register_frame_info
Запускаю, загружается. :) Остаётся собрать приложение и проверить.
make haspdemo - не находит ссылок на __strtoul_internal, __strtol_internal, __fxstat и __fstat. Надо бы чем-то их подменить. Пишу fake-glibc.c следующего содержания:
-------------------------
#include <sys/stat.h>
#includе <stdlib.h>

void *__strtoul_internal = &strtoul;
void *__strtol_internal = &strtol;
void *__xstat = &stat;
void *__fxstat = &fstat;
-------------------------
Собираю:
gcc fake-glibc.c -L. -c -o fake-glibc.o
Добавляю в Makefile в правила для сборки haspdemo fake-glibc.o. "make haspdemo" отрабатывает, haspdemo работает.


Теперь вопрос. Как всё это сделать правильно?

★★★
Ответ на: комментарий от Eshkin_kot

Это понятно, вот только где исходники взять? Не дают же гады :)

qwe ★★★
() автор топика

uClibc бинарно не совместимы с glibc, они только недавно между релизами совместимы стали (опционально). Попробуй всё-таки систему со стандартной glibc, или каждый килобайт важен, что ли?

manntes ★★
()
Ответ на: комментарий от manntes

А какая тут бинарная совместимость библиотек нужна? Поправьте меня если я не прав. Если функции имеют одинаковые заголовки, то и стек при их вызове должен быть одинаковым, а какой бинарный код у функции на одинаковой архитектуре значения иметь не должно.

qwe ★★★
() автор топика
Ответ на: комментарий от qwe

только предположение...

может лучше (чем ковырять бинарники) написать либу враппер и использовать ldpreload?

anonymous
()
Ответ на: комментарий от qwe

>Если функции имеют одинаковые заголовки

Вот-вот, а uClibc довольно-таки альтернативны стандартной библиотеке.

manntes ★★
()
Ответ на: комментарий от manntes

Копаюсь в исходниках uClibc, похоже, что аналогичная функция - __uClibc_main. Правлю бинарник (меняю __libc_start_main на __uClibc_main). Опять пытаюсь запустить:

anonymous
()
Ответ на: комментарий от manntes

>>Если функции имеют одинаковые заголовки

>Вот-вот, а uClibc довольно-таки альтернативны стандартной библиотеке.

Если б они были разными, то исходники написанные для glibc не собирались бы на uClibc.

qwe ★★★
() автор топика
Ответ на: комментарий от anonymous

>может лучше (чем ковырять бинарники) написать либу враппер и использовать ldpreload?

Возможно, но я ж писал, что не программист. :) Да и со стартовой функцией (та которая main запускает) у каждой C библиотеки свои заморочки.

qwe ★★★
() автор топика
Ответ на: комментарий от qwe

Гдето, вроде даже в самих исходниках uClibc была фраза, говорящая, что бинарной совместимости нету (не гарантируется) даже между отдельным релизами uClibc. Бинарная соместимость не связана с тем, что собирается/не собирается, например, при смене релиза в струкутре были переставлены местами (или просто добавлены) поля. Заголовочные (.h-файл) был тоже поправлен. При компиляции в программе будет присутсвовать описание этой (новой) структуры, а программа, скомпилированная со старой библиотекой (старыми заголовочными файлами) может не заработать.

mky ★★★★★
()

>Как всё это сделать правильно?

ИМХО, запустить objdump или что то другое на aksusbd и на haspdemo, собранный для glibc и получить список функций, и для них всех писать враперы, приобразующие данный вызов к glibc в вызов к uClibc. Смотреть исходники glibc и брать оттуда соответсвующее описание структур и т.д. Долго и сложно. Зато если без ошибок, то будет гарантия, что не возникнет странных проблемм из-за бинарной не совместимости uClibc и glibc (сейчас и будущем)...

mky ★★★★★
()
Ответ на: комментарий от mky

>ИМХО, запустить objdump или что то другое на aksusbd и на haspdemo, собранный для glibc и получить список функций, и для них всех писать враперы, приобразующие данный вызов к glibc в вызов к uClibc. Смотреть исходники glibc и брать оттуда соответсвующее описание структур и т.д. Долго и сложно. Зато если без ошибок, то будет гарантия, что не возникнет странных проблемм из-за бинарной не совместимости uClibc и glibc (сейчас и будущем)...

objdump действительно "долго и сложно" (по крайней мере для меня). А вот посмотреть исходники библиотек (или man <функция>), сравнить заголовки десятка функций и решить должна ли работать... :)

>Бинарная соместимость не связана с тем, что собирается/не собирается, например, при смене релиза в струкутре были переставлены местами (или просто добавлены) поля. Заголовочные (.h-файл) был тоже поправлен. При компиляции в программе будет присутсвовать описание этой (новой) структуры, а программа, скомпилированная со старой библиотекой (старыми заголовочными файлами) может не заработать.

С этим согласен. Несовпадение внутренних структур должно привести к непредсказуемым результатам.

qwe ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.