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...