ldd говорит мне, что мое приложение «не динамический исполняемый файл»

17

У меня есть 32-разрядное приложение (называемое uclsyn), которое я получил от профессора астрономии. Мне удалось запустить его на CentOS год назад, но теперь, когда я настраиваю новую виртуальную машину CentOS, она не будет работать, и я не могу понять, почему. Он продолжает возвращаться с "убитым".

Это обмен в командной строке:

$ ./uclsyn_linux
Killed

$ ldd ./uclsyn_linux
not a dynamic executable

$ file ./uclsyn_linux
uclsyn_linux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

На машине, которая работает, «ldd ./uclsyn_linux» возвращает полный список зависимостей. Я нашел пакеты, которые предоставляют эти общие библиотеки, и все они, кажется, установлены.

Требуются пакеты

  • libSM-1.1.0-7.1.el6.i686
  • libX11-1.3-2.el6.i686
  • libgcc-4.4.6-3.el6.i386
  • GLibC-2.12-1.47.el6_2.9.i686
  • libuuid-2.17.2-12.4.el6.i686
  • libXau-1.0.5-1.el6.i686
  • Есть также куча библиотек, локальных для приложения, которые я проверил и уже установил.

Моя среда

CentOS работает под VirtualBox

uname -a: Linux localhost.localdomain 2.6.32-358.el6.i686 # 1 SMP Чт 21 февраля 12:50:49 UTC 2013 i686 i686 i386 GNU / Linux

centos libraries деревенщина
источник
1
дикое предположение: вы пытаетесь запустить 32-разрядный двоичный файл в 64-разрядной ОС без установленных 32-разрядных библиотек.
Михас
Это 32-разрядный двоичный файл, но установленная мной ОС является 32-разрядной версией CentOS. По крайней мере, так говорит команда uname-a, да?
Карл
3
@Carl Из любопытства, что strace ./uclsynвыводит? Это может дать нам подсказку о том, чего не хватает в первую очередь.
lgeorget
@lgeorget, возвращает: execve ("./ uclsyn_linux", ["./uclsyn_linux"], [/ * 56 vars * /] <незаконченный ...> +++ убит SIGKILL +++
Карл
@Carl Хорошо, поэтому он даже не доходит до того, что пытается загрузить некоторые библиотеки. Я никогда не пробовал раньше, чтобы straceпрограмма не была правильно связана.
lgeorget

Ответы:

13

У меня просто была проблема с 32-битным двоичным файлом, решение было:

apt-get install gcc-multilib

$ uname -a
Linux bla 2.6.32-028stab094.3 #1 SMP Thu Sep 22 12:47:37 MSD 2011 x86_64 GNU/Linux
lama12345
источник
3
как вы обнаружили, что эта библиотека отсутствовала?
Yehudahs
1
Это решение сработало для меня. +1
FractalSpace
@yehudahs Я уже довольно давно запускаю множество предкомпилированных 32-битных приложений в Linux, а также реверс-инжиниринг, поэтому я собрал несколько примеров проблем. : D
lama12345
1
хорошо, что это сработало для меня так же, как я царапал свою голову, что я делал неправильно
Марвин Эффинг
1
У меня тоже работает: ldd не нашел что-то, а это работает ^^
jy95
8

Ошибка здесь была из-за нехватки ОЗУ на VirtualMachine. Запуск strace ./programnameпоказал, что программа была убита в момент запуска перед загрузкой любой из библиотек. Увеличение объема доступной оперативной памяти гарантировало работоспособность программы.

Полезные ответы

Были некоторые полезные ответы от других, а именно @slm, который предоставил полезные команды для проверки существования каждой из библиотек, и @lgeorget, который предложил попробовать straceкоманду.

деревенщина
источник
5

Можете ли вы опубликовать некоторые библиотеки, на которые он ссылается (из исходной системы)? Возможно, вам просто нужно установить некоторые недостающие библиотеки.

Обычно в системе CentOS просто нужно запустить команду yum, например:

yum install <package name>

Вы можете работать в обратном направлении от исходной системы следующим образом:

$ ldd /bin/ls
    linux-vdso.so.1 =>  (0x00007fff519ff000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00000034e8e00000)
    librt.so.1 => /lib64/librt.so.1 (0x00000034e8a00000)
    libcap.so.2 => /lib64/libcap.so.2 (0x0000003d6fe00000)
    libacl.so.1 => /lib64/libacl.so.1 (0x00000034fae00000)
    libc.so.6 => /lib64/libc.so.6 (0x00000034e7200000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000034e7a00000)
    /lib64/ld-linux-x86-64.so.2 (0x00000034e6e00000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000034e7e00000)
    libattr.so.1 => /lib64/libattr.so.1 (0x00000034f7600000)

В этом выходе вы можете увидеть , где моя копия /bin/lsнабирает общий .so библиотеки, например , скажем, librt.so.1, что случается, находится здесь: /lib64/librt.so.1.

Зная это, в исходной системе вы можете запустить эту команду, чтобы выяснить, какой пакет предоставляет эту библиотеку:

$ rpm -qf /lib64/librt.so.1
glibc-2.13-2.x86_64

Итак, посылка называется glibc-2.13-2.x86_64. Итак, чтобы установить его, вы должны сделать это:

$ sudo yum install glibc-2.13-2.x86_64
SLM
источник
Большое спасибо за помощь. Я продолжаю. Обновите мой вопрос, добавив больше информации, если вы хотите обновить свой ответ, он будет очень признателен. :)
Карл
Были ли у вас yum install <package>те пакеты, на которые вы ссылались в своем вопросе?
SLM
Да. Все они были установлены, за исключением libuuid.i686, который сейчас есть, но у меня все та же проблема.
Карл
2

Ответ на ваш вопрос: вы пытаетесь запустить приложение, которое было скомпилировано для GNU / Linux год назад, и вы пытаетесь запустить его с новыми библиотеками, которые могут быть несовместимы или недоступны.

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

lgeorget
источник
1
Это не правильно. Программа статически связана, ссылки на библиотеки в хост-системе отсутствуют. Хотя ABI все еще может вызывать несовместимость, это маловероятно между незначительными оборотами ядра Linux (при условии той же архитектуры).
чхан
1
Это не связано статически, смотрите вывод file. И сообщения вроде No package xyz foundпредполагают, что необходимые библиотеки больше не доступны (по крайней мере, не так, как они были, в тех же пакетах). Вот почему я предлагаю перестроить программу, если это возможно, или запустить ее в системе, в которой она работала, со старыми библиотеками.
lgeorget
К сожалению, перекомпиляция здесь не вариант. Я запустил его на другой системе точно так же, как я пытаюсь здесь, но по какой-то причине, на этот раз это не нравится.
Карл
Это не правильно. Изменение адресов не имеет значения вообще. Удаляемые функции или другие прерывания ABI происходят при больших ревизиях библиотеки (которые редки), и в этом случае вы получите ошибку при загрузке libfoo2, если у вас не установлен libfoo2, независимо от того, установлена ​​ли у вас libfoo3 или нет.
Псуси
Хорошо, приятно знать Я думал, что любое изменение в библиотеке может нарушить связь. В настоящее время я использую gentoo, и мне часто приходится перекомпилировать обратные зависимости при обновлении библиотеки, поэтому я не думал, что компоновка настолько устойчива к изменениям библиотеки.
lgeorget
0

попробуйте readelf -l uclsyn_linux запросить программный переводчик и подскажет что вам не хватает.

netawater
источник
1
Я столкнулся readelf -l <file>с файлом с тем же lddповедением ( not a dynamic executable), но я не вижу ничего, указывающего на отсутствующую библиотеку. Я вижу Elf file type is EXEC (Executable file), Entry point, Program Headersи Section to Segment mapping. Что именно я должен искать в выводе?
StockB
0

В Arch Linux , если файл 32-битный elf, вы можете установить lib32-gcc-libs (из multilib-репозитория), чтобы решить эту проблему.

Акула
источник