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

Я думаю, что лучший выбор как сервер, ОС является CentOS даже при том, что Redhat лучше! CentOS является производной от Redhat, это получает Redhat, изменил его немного (на изменении в ядре) и распределил под именем CentOS. Таким образом, эти два - то же. Большое преимущество на CentOS состоит в том, что ее свободной и большим преимуществом Redhat является его обширная и долговременная поддержка. Таким образом, если Вы хотите установить сеть для малого бизнеса или чего-то, что подобный CenOS является лучшим, но если Вы ищете сервер ОС, которая может обработать крупномасштабную или корпоративную сеть, лучшее, кажется, Redhat, Но помнить, что Redhat RHEL является дорогим.

о SUSE: OpenSUSE хорош, мощен, устойчив, безопасен, свободен, ориентирован на сети (!!) но весь уровень понижаются по сравнению с этими упомянутыми выше двумя.

о Ubntu (полученный из Debian): Это испытывает недостаток во всех функциях, которые должен иметь сервер!

17
08.05.2013, 16:10
6 ответов

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

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

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

8
27.01.2020, 19:47

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

Обычно в системе CentOS это - просто вопрос выполнения вкусной команды как так:

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
5
27.01.2020, 19:47
  • 1
    Большое спасибо за справку. Я добираюсь далее. Обновили мой вопрос еще с некоторой информацией теперь, если бы Вы хотите обновить свой ответ с тем же, это очень ценилось бы. :) –  Carl 08.05.2013, 14:44
  • 2
    Сделал Вас yum install <package> те пакеты, на которые Вы сослались в своем вопросе? –  slm♦ 08.05.2013, 14:58
  • 3
    Да я сделал. Они были все установлены за исключением libuuid.i686, который является теперь, но у меня все еще есть та же проблема. –  Carl 08.05.2013, 15:36

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

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

2
27.01.2020, 19:47
  • 1
    Это не корректно. Программа статически связана, никакие библиотеки по хост-системе не будут ссылаемыми. В то время как ABI может все еще вызвать несовместимость, это маловероятно между незначительными версиями ядра Linux (принимающий ту же архитектуру). –  ckhan 08.05.2013, 06:37
  • 2
    Это статически не связано, посмотрите вывод от file. И сообщения как No package xyz found предположите, что необходимые библиотеки больше не доступны (по крайней мере, не способ, которым они были в тех же пакетах). Вот почему я предлагаю восстановить программу, если это возможно, или выполнение его в системе, в которой это, как было известно, работало со старыми библиотеками. –  lgeorget 08.05.2013, 15:03
  • 3
    К сожалению, перекомпиляция не является опцией здесь. Я получил его работающий на другой системе просто таким же образом, я пробую здесь, но по некоторым причинам, на этот раз этому не нравится он. –  Carl 08.05.2013, 16:11
  • 4
    Это неправильно. Изменение адресов не имеет значения вообще. Удаляемые функции или другие повреждения ABI происходят в главных версиях библиотеки (которые редки), в этом случае, Вы получили бы ошибку при загрузке libfoo2, если у Вас нет libfoo2 установленным, есть ли у Вас установленный libfoo3. –  psusi 08.05.2013, 17:23
  • 5
    Хорошо, хороший для знания. Я думал, что любое изменение в библиотеке могло повредить соединение. Я в настоящее время выполняю хинду, и я часто должен перекомпилировать обратные зависимости, когда я обновляю библиотеку, таким образом, я не думал, связываясь, было настолько стойким к изменениям библиотеки. –  lgeorget 08.05.2013, 17:43

У меня просто была проблема с 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
13
27.01.2020, 19:47
  • 1
    , как Вы находили, что тот lib отсутствовал? –  yehudahs 13.01.2015, 14:39
  • 2
    Это решение работало на меня. +1 –  FractalSpace 15.01.2015, 20:59
  • 3
    @yehudahs, я запустил много предварительно скомпилированных приложений на 32 бита на Linux долгое время плюс Инженерный анализ их, таким образом, я собрал некоторую проблему, стреляющую в события. :D –  lama12345 07.08.2016, 07:46

try readelf -l uclsyn_linux Запрос интерпретатора программы скажет вам, чего вам не хватает.

0
27.01.2020, 19:47

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

0
27.01.2020, 19:47

Теги

Похожие вопросы