GRUB не показывает все ОС

ldd перечисляет разделяемые библиотеки, которые требуются для его аргумента. С опцией -vотображается вся доступная информация, включая символы версий.

Строки вида

linux-vdso.so.1 =>  (0x00007fffa3dff000)
librt.so.1 => /lib64/librt.so.1 (0x00007fea7a7b2000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fea7a4ab000)

список библиотек, требуемых libAtlasUtilsPB.so, и способы их разрешения; в вашем случае все необходимые библиотеки найдены. linux-vdso.so.1особенная, это виртуальная библиотека , предоставляемая ядром.

Строки вида

libgcc_s.so.1 (GCC_3.0) => /lib64/libgcc_s.so.1
libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6
libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0

перечисляет символы версии, требуемые libAtlasUtilsPB.so, и опять же, как они разрешаются. Именно здесь lddне удается разрешить элементы, на что он указывает как указанием «не найдено» здесь, так и выводом сообщений об ошибках в начале своего вывода.

GLIBC_..., GLIBCXX_...и т. д. — это символы версий, которые используются в некоторых библиотеках (, включая библиотеку GNU C и библиотеки GCC ), для определения требуемых версий и управления обратной совместимостью. Двоичный (исполняемый файл или библиотека )обычно требуют нескольких версий в зависимости от символов, которые он действительно использует из целевой библиотеки. Чтобы удовлетворить требования данного двоичного файла, вам необходимо предоставить библиотеку, которая поддерживает все требуемые версии — , т. е. библиотеку, соответствующую как минимум самому старшему символу версии в списке требований.

Причина, по которой может потребоваться несколько версий, заключается в том, что каждый импортированный объект (, функция и т. д. )может иметь версию, и данный двоичный файл может связываться с несколькими версиями во всех функциях, которые он использует. Например, выбрав пример с двумя версиями в моей системе, /lib/x86_64-linux-gnu/libgcc_s.so.1, ldd -vпоказывает

/lib/x86_64-linux-gnu/libgcc_s.so.1:
        libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
        libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6

libgcc_s.so.1требуется два символа версии из libc.so.6. Чтобы понять почему, нам нужно взглянуть на содержащиеся в нем неопределенные символы — это символы, которые ему нужно импортировать :

.

$ objdump -T /lib/x86_64-linux-gnu/libgcc_s.so.1|grep -F '*UND*'
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 dl_iterate_phdr
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 free
0000000000000000  w   D  *UND*  0000000000000000              __pthread_key_create
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 abort
0000000000000000  w   D  *UND*  0000000000000000              _ITM_deregisterTMCloneTable
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 strlen
0000000000000000  w   D  *UND*  0000000000000000              pthread_getspecific
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 memset
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 calloc
0000000000000000  w   D  *UND*  0000000000000000              pthread_key_create
0000000000000000  w   D  *UND*  0000000000000000              __gmon_start__
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.14  memcpy
0000000000000000  w   D  *UND*  0000000000000000              pthread_once
0000000000000000  w   DF *UND*  0000000000000000  GLIBC_2.2.5 pthread_mutex_unlock
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 malloc
0000000000000000  w   D  *UND*  0000000000000000              pthread_setspecific
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 realloc
0000000000000000  w   D  *UND*  0000000000000000              _Jv_RegisterClasses
0000000000000000  w   D  *UND*  0000000000000000              _ITM_registerTMCloneTable
0000000000000000  w   DF *UND*  0000000000000000  GLIBC_2.2.5 __cxa_finalize
0000000000000000  w   DF *UND*  0000000000000000  GLIBC_2.2.5 pthread_mutex_lock

Здесь перечислены несколько версий символов (с GLIBC_2.2.5или GLIBC_2.14во втором -последнем столбце ),и мы можем видеть здесь, что версии совпадают с теми, которые мы видели с ldd. Почему мы получаем символы нескольких версий? Вот тут-то и появляется обратная совместимость. Версия 2.2.5 является базовой для управления версиями символов в библиотеке GNU C; любая функция, которая присутствовала в версии 2.2.5, относится к этой версии. В версии 2.13 библиотеки GNU C поведение memcpyбыло изменено; это сломало ряд программ, поэтому в версии 2.14 обратно совместимая версия -была добавлена ​​​​с необязательным тегом версии GLIBC_2.2.5, а новая версия добавлена ​​​​с тегом версии GLIBC_2.14. Таким образом, старые двоичные файлы, созданные с использованием более ранних версий библиотеки C, используют старую версию memcpy, а двоичные файлы, созданные с использованием версии 2.14 и более поздних, используют новую версию memcpy.

Та же история применима к libstdc++.so.6, но со многими другими изменениями с обновленными номерами версий; Подробная информация содержится в руководстве libstdc++.

В вашем случае вам нужно, чтобы libstdc++.so.6соответствовало GLIBCXX_3.4.18, , то есть версии, предоставленной GCC 4.8.0 или более поздней версии, и версии 2.14 библиотеки GNU C.

Вы не можете легко создавать двоичные файлы на RHEL 7 и запускать их на RHEL 6 (, поэтому основная версия отличается ). Вам лучше пересобрать свою программу на RHEL 6...