Я думаю, что лучший выбор как сервер, ОС является CentOS даже при том, что Redhat лучше! CentOS является производной от Redhat, это получает Redhat, изменил его немного (на изменении в ядре) и распределил под именем CentOS. Таким образом, эти два - то же. Большое преимущество на CentOS состоит в том, что ее свободной и большим преимуществом Redhat является его обширная и долговременная поддержка. Таким образом, если Вы хотите установить сеть для малого бизнеса или чего-то, что подобный CenOS является лучшим, но если Вы ищете сервер ОС, которая может обработать крупномасштабную или корпоративную сеть, лучшее, кажется, Redhat, Но помнить, что Redhat RHEL является дорогим.
о SUSE: OpenSUSE хорош, мощен, устойчив, безопасен, свободен, ориентирован на сети (!!) но весь уровень понижаются по сравнению с этими упомянутыми выше двумя.
о Ubntu (полученный из Debian): Это испытывает недостаток во всех функциях, которые должен иметь сервер!
Ошибка здесь происходила из-за не наличия достаточного количества RAM на VirtualMachine. Выполнение strace ./programname
обозначенный, что программа закрывалась так же, как она начала работать, прежде, чем загружать любую из библиотек. Увеличение суммы доступной RAM гарантировало, что программа могла работать.
Полезные ответы
Были некоторые полезные ответы от других а именно, @slm, кто обеспечил полезные команды, чтобы проверить, что каждая из библиотек существовала, и @lgeorget кто, предлагая попытку strace
команда.
Можно ли отправить некоторые библиотеки, которые это действительно связывает с (от исходной системы)? Вы, возможно, просто должны были бы установить некоторые недостающие библиотеки.
Обычно в системе 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
yum install <package>
те пакеты, на которые Вы сослались в своем вопросе?
– slm♦
08.05.2013, 14:58
Ответ находится в Вашем вопросе: Вы пытаетесь запустить приложение, которое было скомпилировано для GNU/Linux один год назад, и Вы пытаетесь выполнить его с новыми библиотеками, которые не могут быть совместимыми или больше доступными.
На данном этапе у Вас есть два варианта. Если можно перекомпилировать его (относительно которого я сомневаюсь, если я пойму хорошо случай), то это будет работать, потому что это будет повторно связано с совместимыми библиотеками. Иначе Вы могли попытаться создать своего рода песочницу, VM, работающий со старой версией библиотек GNU, например, запустить приложение в.
file
. И сообщения как No package xyz found
предположите, что необходимые библиотеки больше не доступны (по крайней мере, не способ, которым они были в тех же пакетах). Вот почему я предлагаю восстановить программу, если это возможно, или выполнение его в системе, в которой это, как было известно, работало со старыми библиотеками.
– lgeorget
08.05.2013, 15:03
У меня просто была проблема с 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
try readelf -l uclsyn_linux
Запрос интерпретатора программы скажет вам, чего вам не хватает.
В Arch Linux , если файл 32 -бит elf, вы можете установить lib32 -gcc -libs(из репозитория multilib )для решения эта проблема.