Можно ли использовать LD_PRELOAD для загрузки разных версий glibc?

Состав персонажей

  • big-old-app связан со старой версией glibc, скажем, glibc-2.12. Я ничего не могу сделать, чтобы изменить это.
  • cute-new-addon.o связан с более новой версией, glibc-2.23. Этот glibc-2.23 находится по нестандартному пути (потому что у меня нет полномочий sudo).

История

Я хочу использовать cute-new-addon.o внутри big-old-app. Обычно я бы написал сценарий для выполнения big-old-app, который затем вызывает cute-new-addon.o для выполнения своих трюков. Из командной строки это будет выглядеть так:

$ big-old-app script.txt

Однако, когда я это сделаю, big-old-app будет жаловаться, что cute-new-addon.o не может найти glibc-2.23. Это понятно, потому что я не указал никаких стандартных путей. Что, если я сделаю:

$ LD_LIBRARY_PATH=/path/to/mylibs:$LD_LIBRARY_PATH big-old-app script.txt

Это segfaults! :(

Я думаю, это потому, что big-old-app ссылается на более новый mylibc.so.6. При этом реализации больше не являются теми, к которым привык big-old-app, поэтому возникают ошибки.

Вопрос

Что касается script.txt, я не думаю, что у меня есть возможность указать более новый mylibc.so.6 перед вызовом cute-new-addon.o. big-old-app и cute-new-addon.o тесно переплетены, и я не могу знать, когда кому-то из них понадобится соответствующий glibc.

И да, cute-new-addon.o rpath указывает на /path/to/mylibs и я могу подтвердить через ldd, что все нужные ему библиотеки он ищет в /path/to/mylibs.

Могу ли я использовать LD_PRELOAD для загрузки двух разных версий glibc? И пусть big-old-app и cute-new-addon.o ищут то, что им нужно, как им вздумается?


person Kit    schedule 15.03.2019    source источник
comment
stackoverflow.com/a/851229/50617 содержит объяснение, почему LD_PRELOAD не работает, и возможные обходные пути.   -  person Employed Russian    schedule 17.03.2019


Ответы (1)


LD_PRELOAD нельзя использовать, потому что динамический компоновщик glibc (иногда называемый ld.so или программным интерпретатором; расположение на диске зависит от платформы) совместим только с libc.so.6 (и остальными библиотеками) из той же сборки glibc.

Вы можете использовать явный вызов загрузчиком другого glibc вместе с настройками пути к библиотеке, которые заставят загрузчик загружать объекты glibc из отдельного каталога, а не из системных каталогов. В вики glibc есть пример того, как это сделать.

person Florian Weimer    schedule 15.03.2019
comment
Сборка glibc без установки : ... Префикс /usr считается правильным префиксом для системной glibc. У меня такое ощущение, что это необходимо для загрузки объектов glibc из отдельного каталога. Я на правильном пути? - person Kit; 15.03.2019
comment
Нет, вы можете собрать с помощью --prefix=/usr и по-прежнему хранить копию в отдельном месте, возможно, установив ее с помощью make install DESTDIR=/path/to/alternative/tree. - person Florian Weimer; 15.03.2019