Безопасно ли динамически связываться с более старыми версиями символов glibc, используя функции-обертки? - PullRequest
Новая
       74

Безопасно ли динамически связываться с более старыми версиями символов glibc, используя функции-обертки?

3 голосов
/ 23 сентября 2019

Я следую указаниям здесь Связывание со старой версией libc для обеспечения большего охвата приложения для создания .so (библиотека JNI, встроенная в JAR), которая может работать на более старых версияхLinux.У меня также есть несколько статических библиотек, в которые я добавляю ссылки, поэтому я создаю оболочки, как предложено в этом ответе .

В частности, я собираю библиотеку в файле Docker, работающем GCC8.3.0 в Ubuntu 19.04 .Затем я связываю файл C, как показано ниже (о котором источники / библиотеки не знают до стадии связывания): 

double __exp_2_2_5(double);
asm(".symver __exp_2_2_5, exp@GLIBC_2.2.5");
double __wrap_exp(double a) { return __exp_2_2_5(a); }

Исходные файлы были просто собраны, ссылаясь на exp, что обычноразрешить до exp@GLIBC_2.29.Однако функция обертки добавляется во время соединения с помощью: 

-Wl,--wrap=exp

Этот отображается для работы на других машинах, на которых я его тестировал (Ubuntu 18 и Alpine 3.10 Dockerпока что, но постараюсь еще назад).Однако я хочу знать, совместим ли общий подход с ABI.

Функции, которые я хотел бы заменить (неисчерпывающий список, поскольку в конечном итоге может появиться больше):

  • exp@GLIBC_2.29
  • clock_gettime@GLIBC_2.17
  • memcpy@GLIBC_2.14

Является ли этот общий подход приемлемым или я столкнусь с проблемами рано или поздно?Я чувствую, что есть вероятность, что мой источник (или библиотека) ссылается на функцию таким образом, что ее нельзя обернуть тривиально.

РЕДАКТИРОВАТЬ: , чтобы быть понятным, я все еще динамически связывая с этими символами.Я просто изменяю версию, с которой я динамически связываюсь.

...