Несколько библиотек glibc на одном хосте

использовать LD_PRELOAD: поместите свою библиотеку где-нибудь из каталогов Man lib и запустите:

LD_PRELOAD='mylibc.so anotherlib.so' program

посмотреть: Википедия

этот вопрос старый, другие ответы старые. Ответ "Employed Russian" очень хорош и информативен, но он работает только в том случае, если у вас есть исходный код. Если вы этого не сделаете, альтернативы тогда были очень сложными. К счастью, в настоящее время у нас есть простое решение этой проблемы (как прокомментировано в одном из его ответов), используя patchelf. Все, что вам нужно сделать, это:

$ ./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 --set-rpath /path/to/newglibc/ myapp

и после этого, вы можете просто выполнить файл:

$ ./myapp

не нужно chroot или вручную редактировать двоичные файлы, к счастью. Но не забудьте сделать резервную копию двоичного файла перед его исправлением, если вы не уверены, что делаете, потому что он изменяет ваш двоичный файл. После исправления вы не можете восстановить старый путь к интерпретатору/rpath. Если это не сработает, вам придется латать его, пока вы не найдете тот путь, который действительно будет работать... Ну, это не обязательно должен быть процесс проб и ошибок. Например, в Примере опа ему нужно было GLIBC_2.3, так что вы можете легко найти, какие lib предоставляет эту версию с помощью strings:

$ strings /lib/i686/libc.so.6 | grep GLIBC_2.3
$ strings /path/to/newglib/libc.so.6 | grep GLIBC_2.3

теоретически, первый grep будет пустым, потому что система libc не имеет версии, которую он хочет, а второй должен выводить GLIBC_2.3, потому что у него есть версия myapp использует, поэтому мы знаем, что можем patchelf наш двоичный файл, используя этот путь.

когда вы пытаетесь запустить двоичный файл в linux, двоичный файл пытается загрузить компоновщик, а затем библиотеки, и все они должны быть в пути и/или в нужном месте. Если ваш проблема с компоновщиком, и вы хотите узнать, какой путь ищет ваш двоичный файл, вы можете узнать с помощью этой команды:

$ readelf -l myapp | grep interpreter
  [Requesting program interpreter: /lib/ld-linux.so.2]                                                                                                                                                                                   

если ваша проблема связана с библиотеками, команды, которые дадут вам используемые библиотеки:

$ readelf -d myapp | grep Shared
$ ldd myapp 

это будет список библиотек, которые нужны вашему двоичному файлу, но вы, вероятно, уже знаете проблемные, так как они уже дают ошибки, как в случае OP.

"patchelf" работает для многих различных проблем, которые вы можете столкнуться при попытке запустить программу, связанную с этими 2 проблемами. Например, если вы получаете: ELF file OS ABI invalid, это может быть исправлено путем установки нового загрузчика (--set-interpreter часть команды), как я объясню здесь. Другой пример - проблема получения No such file or directory когда вы запускаете файл, который есть и исполняемый файл, как показано на примере здесь. В этом конкретном случае OP отсутствовала ссылка на загрузчик, но, возможно, в вашем случае у вас нет корневого доступа и не может создать ссылку. Установка нового интерпретатора решит вашу проблему.

Спасибо русским и Михаилу Панкову за понимание и решение!

вы можете рассмотреть возможность использования Nix http://nixos.org/nix/ ?

Nix поддерживает многопользовательское управление пакетами: несколько пользователей могут совместно использовать общее хранилище Nix безопасно, не нужно иметь привилегии root установите программное обеспечение, и могут установить и использовать различные версии пакет.

прежде всего, наиболее важной зависимостью каждой динамически связанной программы является компоновщик. Все библиотеки so должны соответствовать версии компоновщика.

давайте возьмем простой пример: у меня есть система newset ubuntu, где я запускаю некоторую программу (в моем случае это компилятор D - ldc2). Я хотел бы запустить его на старом CentOS, но из-за старой библиотеки glibc это невозможно. Я получил

ldc2-1.5.0-linux-x86_64/bin/ldc2: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by ldc2-1.5.0-linux-x86_64/bin/ldc2)
ldc2-1.5.0-linux-x86_64/bin/ldc2: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ldc2-1.5.0-linux-x86_64/bin/ldc2)

Я должен скопировать все зависимости из ubuntu в centos. Надлежащий метод это следующее:

во-первых, давайте проверим все зависимости:

ldd ldc2-1.5.0-linux-x86_64/bin/ldc2 
    linux-vdso.so.1 =>  (0x00007ffebad3f000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f965f597000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f965f378000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f965f15b000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f965ef57000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f965ec01000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f965e9ea000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f965e60a000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f965f79f000)

linux-vdso.so.1 не является реальной библиотекой, и мы не должны заботиться о нем.

/lib64 / ld-linux-x86-64.so.2-это компоновщик, который используется linux для связывания исполняемого файла со всеми динамическими библиотеками.

остальные файлы являются реальными библиотеками, и все они вместе с компоновщиком должны быть скопированы где-то в centos.

предположим, что все библиотеки и компоновщик находится в каталоге "/mylibs".

ЛД-ОС Linux для архитектуры x86-64.так.2 - как я уже сказал - это компоновщик. Это не динамическая библиотека, а статический исполняемый файл. Вы можете запустить его и увидеть, что он даже имеет некоторые параметры, например --library-path (я вернусь к нему).

на Linux, динамически скомпонованной программы может быть запущено только по его имени, например

/bin/ldc2

Linux загружает такую программу в оперативную память и проверяет, какой компоновщик установлен для нее. Обычно, на 64-битной системе, это /lib64 / ld-linux-x86-64.so.2 (в вашей файловой системе это символическая ссылка на реальный исполняемый файл). Затем linux запускает компоновщик и загружает динамические библиотеки.

вы также можете немного изменить это и сделать такой трюк:

/mylibs/ld-linux-x86-64.so.2 /bin/ldc2

это способ заставить linux использовать определенный компоновщик.

и теперь мы можем вернуться к упомянутому ранее параметру -- library-path

/mylibs/ld-linux-x86-64.so.2 --library-path /mylibs /bin/ldc2

он будет запускать ldc2 и загружать динамические библиотеки из /mylibs.

это метод для вызова исполняемого файла с выбранными (не системными по умолчанию) библиотеками.

Если вы внимательно посмотрите на второй вывод, вы можете увидеть, что используется новое расположение для библиотек. Возможно, все еще отсутствуют библиотеки, которые являются частью glibc.

Я тоже думаю, что все библиотеки, используемые программой, должны быть скомпилированы, что версия glibc. Если у вас есть доступ к исходному коду программы, Новая компиляция кажется лучшим решением.

"нанятый русский" является одним из лучших ответов, и я думаю, что все другие предлагаемые ответы могут не работать. Причина заключается просто в том, что при первом создании приложения все его API, необходимые для него, разрешаются во время компиляции. Используя " ldd " u можно увидеть все статически связанные зависимости:

ldd /usr/lib/firefox/firefox
    linux-vdso.so.1 =>  (0x00007ffd5c5f0000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f727e708000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f727e500000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f727e1f8000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f727def0000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f727db28000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f727eb78000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f727d910000)

но во время выполнения firefox также загружает многие другие динамические библиотеки, например (для firefox) есть много "glib"-помеченных библиотек, загруженных (хотя статически связанные есть нет):

 /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2.2.2
 /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0
 /usr/lib/x86_64-linux-gnu/libavahi-glib.so.1.0.2

Manytimes, вы можете видеть имена одной версии, которые мягко связаны с другой версией. Например:

lrwxrwxrwx 1 root root     23 Dec 21  2014 libdbus-glib-1.so.2 -> libdbus-glib-1.so.2.2.2
-rw-r--r-- 1 root root 160832 Mar  1  2013 libdbus-glib-1.so.2.2.2

это означает, что в одной системе существует разная версия "библиотек", что не является проблемой, поскольку это один и тот же файл, и он обеспечит совместимость, когда приложения имеют несколько зависимостей версий.

таким образом, на системном уровне все библиотеки почти взаимозависимы друг от друга и просто меняют приоритет загрузки библиотек через манипулирование LD_PRELOAD или LD_LIBRARY_PATH не поможет - даже он может загрузиться, во время выполнения он все равно может произойти сбой.

http://lightofdawn.org/wiki/wiki.cgi/-wiki/NewAppsOnOldGlibc

лучшая альтернатива-chroot (кратко упомянутый ER): но для этого вам нужно будет воссоздать всю среду, в которой находится исходное двоичное выполнение - обычно начиная с /lib, /usr/lib/, /usr/lib/x86 и т. д. Вы можете либо использовать "Buildroot", или YoctoProject, или просто tar из существующей среды дистрибутива. (например, Fedora / Suse и т. д.).

Я не уверен, что вопрос все еще актуален, но есть еще один способ решения проблемы: Докер. Можно установить почти пустой контейнер исходного дистрибутива (дистрибутив, используемый для разработки) и скопировать файлы в контейнер. Таким образом, вам не нужно создавать файловую систему, необходимую для chroot.

Setup 1: скомпилируйте свой собственный glibc без выделенного GCC и используйте его

Эта настройка может работать и быстро, поскольку она не перекомпилирует всю цепочку инструментов GCC, а только glibc.

но он не является надежным, поскольку он использует объекты времени выполнения host C, такие как crt1.o,crti.o и crtn.o библиотеку glibc. Это упоминается по адресу: https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location те объекты делают раннюю настройку, на которую опирается glibc, поэтому я не удивлюсь, если все рухнет чудесным и потрясающе тонким образом.

для более надежной настройки см. раздел настройка 2 ниже.

построить glibc и установить локально:

export glibc_install="$(pwd)/glibc/build/install"

git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28
mkdir build
cd build
../configure --prefix "$glibc_install"
make -j `nproc`
make install -j `nproc`

настройка 1: Проверьте сборку

test_glibc.c

#define _GNU_SOURCE
#include <assert.h>
#include <gnu/libc-version.h>
#include <stdatomic.h>
#include <stdio.h>
#include <threads.h>

atomic_int acnt;
int cnt;

int f(void* thr_data) {
    for(int n = 0; n < 1000; ++n) {
        ++cnt;
        ++acnt;
    }
    return 0;
}

int main(int argc, char **argv) {
    /* Basic library version check. */
    printf("gnu_get_libc_version() = %s\n", gnu_get_libc_version());

    /* Exercise thrd_create from -pthread,
     * which is not present in glibc 2.27 in Ubuntu 18.04.
     * https://stackoverflow.com/questions/56810/how-do-i-start-threads-in-plain-c/52453291#52453291 */
    thrd_t thr[10];
    for(int n = 0; n < 10; ++n)
        thrd_create(&thr[n], f, NULL);
    for(int n = 0; n < 10; ++n)
        thrd_join(thr[n], NULL);
    printf("The atomic counter is %u\n", acnt);
    printf("The non-atomic counter is %u\n", cnt);
}

компиляция и запуск с test_glibc.sh:

#!/usr/bin/env bash
set -eux
gcc \
  -L "${glibc_install}/lib" \
  -I "${glibc_install}/include" \
  -Wl,--rpath="${glibc_install}/lib" \
  -Wl,--dynamic-linker="${glibc_install}/lib/ld-linux-x86-64.so.2" \
  -std=c11 \
  -o test_glibc.out \
  -v \
  test_glibc.c \
  -pthread \
;
ldd ./test_glibc.out
./test_glibc.out

программа выводит ожидаемое:

gnu_get_libc_version() = 2.28
The atomic counter is 10000
The non-atomic counter is 8674

адаптировано из https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location но --sysroot сделал это сбой с:

cannot find /home/ciro/glibc/build/install/lib/libc.so.6 inside /home/ciro/glibc/build/install

поэтому я удалил его.

ldd вывод подтверждает, что ldd и библиотеки, которые мы только что построили, фактически используются так, как ожидалось:

+ ldd test_glibc.out
        linux-vdso.so.1 (0x00007ffe4bfd3000)
        libpthread.so.0 => /home/ciro/glibc/build/install/lib/libpthread.so.0 (0x00007fc12ed92000)
        libc.so.6 => /home/ciro/glibc/build/install/lib/libc.so.6 (0x00007fc12e9dc000)
        /home/ciro/glibc/build/install/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc12f1b3000)

The gcc выходные данные отладки компиляции показывают, что использовались объекты среды выполнения моего хоста, что плохо, поскольку упоминалось ранее, но я не знаю, как обойти это, например, он содержит:

COLLECT_GCC_OPTIONS=/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crt1.o

настройка 1: изменить glibc

теперь давайте изменим glibc с:

diff --git a/nptl/thrd_create.c b/nptl/thrd_create.c
index 113ba0d93e..b00f088abb 100644
--- a/nptl/thrd_create.c
+++ b/nptl/thrd_create.c
@@ -16,11 +16,14 @@
    License along with the GNU C Library; if not, see
    <http://www.gnu.org/licenses/>.  */

+#include <stdio.h>
+
 #include "thrd_priv.h"

 int
 thrd_create (thrd_t *thr, thrd_start_t func, void *arg)
 {
+  puts("hacked");
   _Static_assert (sizeof (thr) == sizeof (pthread_t),
                   "sizeof (thr) != sizeof (pthread_t)");

затем перекомпилировать и переустановить glibc, а также перекомпилировать и повторно запустить нашу программу:

cd glibc/build
make -j `nproc`
make -j `nproc` install
./test_glibc.sh

и мы видим hacked печатается несколько раз, как и ожидалось.

это еще раз подтверждает, что мы фактически использовали glibc, который мы скомпилировали, а не хост один.

протестировано на Ubuntu 18.04.

Setup 2: crosstool - ng pristine setup

это альтернатива setup 1, и это самая правильная настройка, которую я достиг далеко: все правильно, насколько я могу наблюдать, включая объекты времени выполнения C, такие как crt1.o,crti.o и crtn.o.

в этой настройке мы скомпилируем полную выделенную цепочку инструментов GCC, которая использует glibc, который мы хотим.

единственный недостаток этого метод заключается в том, что сборка займет больше времени. Но я бы не стал рисковать производственной установкой с чем-то меньшим.

crosstool-NG это набор скриптов, который загружает и компилирует все из источника для нас, включая GCC, glibc и binutils.

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

Эта настройка не идеальна только потому, что crosstool-NG не поддерживает построение исполняемых файлов без экстра -Wl флаги, что кажется странным, так как мы построили сам GCC. Но все вроде бы работает, так что это только неудобство.

получить crosstool-NG и настроить его:

git clone https://github.com/crosstool-ng/crosstool-ng
cd crosstool-ng
git checkout a6580b8e8b55345a5a342b5bd96e42c83e640ac5
export CT_PREFIX="$(pwd)/.build/install"
export PATH="/usr/lib/ccache:${PATH}"
./bootstrap
./configure --enable-local
make -j `nproc`
./ct-ng x86_64-unknown-linux-gnu
./ct-ng menuconfig

единственный обязательный параметр, который я вижу, - это соответствие версии ядра хоста для использования правильных заголовков ядра. Найдите свою версию ядра хоста с помощью:

uname -a

который показывает мне:

4.15.0-34-generic

так menuconfig I делать:

• Operating System
  • Version of linux

поэтому я выбираю:

4.14.71

это первая равная или более старая версия. Он должен быть старше, так как ядро обратно совместимо.

теперь вы можете строить:

env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`

а теперь подождите около тридцати минут до двух часов для компиляции.

настройка 2: дополнительные конфигурации

в .config что мы создали с ./ct-ng x86_64-unknown-linux-gnu есть:

CT_GLIBC_V_2_27=y

чтобы изменить это, в menuconfig do:

• C-library
• Version of glibc

сохранить .config, и продолжить строить.

или, если вы хотите использовать свой собственный источник glibc, например, чтобы использовать glibc из последнего git, продолжайте такой:

• Paths and misc options
  • Try features marked as EXPERIMENTAL: установить правда
• C-library
  • Source of glibc
    • Custom location: сказать да
    • Custom location
      • Custom source location: укажите на каталог, содержащий ваш источник glibc

где glibc был клонирован как:

git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28

настройка 2: проверьте его

после того, как вы построили он toolchain, что вы хотите, проверить его долой:

#!/usr/bin/env bash
set -eux
install_dir="${CT_PREFIX}/x86_64-unknown-linux-gnu"
PATH="${PATH}:${install_dir}/bin" \
  x86_64-unknown-linux-gnu-gcc \
  -Wl,--dynamic-linker="${install_dir}/x86_64-unknown-linux-gnu/sysroot/lib/ld-linux-x86-64.so.2" \
  -Wl,--rpath="${install_dir}/x86_64-unknown-linux-gnu/sysroot/lib" \
  -v \
  -o test_glibc.out \
  test_glibc.c \
  -pthread \
;
ldd test_glibc.out
./test_glibc.out

все, кажется, работает как в Setup 1, за исключением того, что теперь использовались правильные объекты времени выполнения:

COLLECT_GCC_OPTIONS=/home/ciro/crosstool-ng/.build/install/x86_64-unknown-linux-gnu/bin/../x86_64-unknown-linux-gnu/sysroot/usr/lib/../lib64/crt1.o

Setup 2: неудачная попытка эффективной перекомпиляции glibc

это не представляется возможным с crosstool-NG, как описано ниже.

если вы просто перестроить;

env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`

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

если мы это сделаем:

./ct-ng list-steps

это дает хороший обзор этапов построения:

Available build steps, in order:
  - companion_tools_for_build
  - companion_libs_for_build
  - binutils_for_build
  - companion_tools_for_host
  - companion_libs_for_host
  - binutils_for_host
  - cc_core_pass_1
  - kernel_headers
  - libc_start_files
  - cc_core_pass_2
  - libc
  - cc_for_build
  - cc_for_host
  - libc_post_cc
  - companion_libs_for_target
  - binutils_for_target
  - debug
  - test_suite
  - finish
Use "<step>" as action to execute only that step.
Use "+<step>" as action to execute up to that step.
Use "<step>+" as action to execute from that step onward.

поэтому мы видим, что есть шаги glibc, переплетенные с несколькими шагами GCC, в первую очередь libc_start_files перед cc_core_pass_2, что, вероятно, самый дорогой Шаг вместе с cc_core_pass_1.

чтобы построить только один шаг, вы должны сначала установить "сохранить промежуточные шаги" в для начальная сборка:

• Paths and misc options
  • Debug crosstool-NG
    • Save intermediate steps

и тогда вы можете попробовать:

env -u LD_LIBRARY_PATH time ./ct-ng libc+ -j`nproc`

но, к сожалению,+ требуется, как указано в: https://github.com/crosstool-ng/crosstool-ng/issues/1033#issuecomment-424877536

однако обратите внимание, что перезапуск на промежуточном шаге сбрасывается каталог установки в состояние, которое он имел во время этого шага. Т. е. у вас будет перестроенный libc - но нет окончательного компилятора, построенного с этим libc (и, следовательно, нет библиотек компиляторов, таких как libstdc++).

и в основном все еще делает перестройку слишком медленной, чтобы быть возможной для развития, и я не вижу, как преодолеть это без исправления crosstool-NG.

кроме того, начиная с libc шаг, похоже, не копировал источник снова из Custom source location, что делает этот метод непригодным для использования.

бонус: stdlibc++

бонус, если вы также заинтересованы в стандартной библиотеке C++: как изменить и перестроить источник стандартной библиотеки GCC libstdc++ C++?

когда я хотел запустить Chromium-браузер на Ubuntu precise (glibc-2.15), я получил (типичный) сообщение "...файл libc.так.6: GLIBC_2 версия`.19' не найдены...". Я учел тот факт, что файлы не нужны постоянно, а только для начала. Поэтому я собрал файлы, необходимые для браузера и sudo, и создал мини-glibc-2.19- среда, запустил браузер, а затем скопировал исходные файлы обратно снова. Необходимые файлы находятся в оперативной памяти, а оригинальный glibc-это тот же.

as root
the files (*-2.15.so) already exist 

mkdir-p/glibc-2.19 / i386-linux-gnu

/glibc-2.19/ld-linux.so.2 -> /glibc-2.19/i386-linux-gnu/ld-2.19.so
/glibc-2.19/i386-linux-gnu/libc.so.6 -> libc-2.19.so
/glibc-2.19/i386-linux-gnu/libdl.so.2 -> libdl-2.19.so
/glibc-2.19/i386-linux-gnu/libpthread.so.0 -> libpthread-2.19.so

mkdir-p/glibc-2.15 / i386-linux-gnu

/glibc-2.15/ld-linux.so.2 -> (/glibc-2.15/i386-linux-gnu/ld-2.15.so)
/glibc-2.15/i386-linux-gnu/libc.so.6 -> (libc-2.15.so)
/glibc-2.15/i386-linux-gnu/libdl.so.2 -> (libdl-2.15.so)
/glibc-2.15/i386-linux-gnu/libpthread.so.0 -> (libpthread-2.15.so)

скрипт для запуска браузера:

#!/bin/sh
sudo cp -r /glibc-2.19/* /lib
/path/to/the/browser &
sleep 1
sudo cp -r /glibc-2.15/* /lib
sudo rm -r /lib/i386-linux-gnu/*-2.19.so