Как бороться с дублированными .so файлами? - PullRequest
Новая
       13

Как бороться с дублированными .so файлами?

1 голос
/ 30 мая 2019

Я получаю неправильный .so во время выполнения, хотя я указал правильный во время компиляции: 

samiam@samiam-linux-pc:~/projects/petit_ami$ make event
gcc -g3 -o event xterm.c event.c libc.so -lm 
samiam@samiam-linux-pc:~/projects/petit_ami$ ./event
./event: relocation error: ./event: symbol ovr_write version 
GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
samiam@samiam-linux-pc:~/projects/petit_ami$ ldd event
    linux-vdso.so.1 (0x00007ffda5ffa000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe641048000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe641642000)
samiam@samiam-linux-pc:~/projects/petit_ami$

Я использую альтернативный glibc .so, расположенный в текущем каталоге.Мне удалось доказать, что gcc ссылается на правильную библиотеку, потому что, если я удаляю файл libc.so, он жалуется на отсутствующие файлы.Кроме того, если я удаляю файл libc.so из командной строки gcc, я получаю недостающую ссылку во время выполнения.

Таким образом, gcc работает против моего libc.so во время компиляции, но во время выполнения он переходит кстандартное расположение для libc.so вместо локального файла.LD_DEBUG также показывает это поведение.Я также попытался поставить "."на LIBRARY_PATH в первой позиции это никак не отразилось.

Идеальным ответом было бы размещение каталога в порядке поиска перед другими (как я пытался сделать с LIBRARY_PATH), поскольку я определяю несколько локальныхlibs, не все с одинаковыми именами.

...