Как динамически ссылаться на локальную копию libc.so.6, libstdC++.so.6 в системе со старой версией gcc

Мой код написан на C++2011 и скомпилирован в g++ 4.8. однако мой системный администратор не будет обновлять вычислительный кластер с gcc/g++ 4.1. я получаю следующую ошибку:

/lib64/libc.so.6: версия `GLIBC_2.14'не найдена (требуется./ManRegOptDes)
/usr/lib64/libstdc++.so.6: версия `GLIBCXX_3.4.17'не найдена (требуется./ManRegOptDes)
/usr/lib64/libstdc++.so.6: версия `GLIBCXX_3.4.11'не найдена (требуется./ManRegOptDes)
/usr/lib64/libstdc++.so.6: версия `GLIBCXX_3.4.9'не найдена (требуется./ManRegOptDes)
/usr/lib64/libstdc++.so.6: версия `GLIBCXX_3.4.13'не найдена (требуется./ManRegOptDes)
/usr/lib64/libstdc++.so.6: версия `GLIBCXX_3.4.19'не найдена (требуется./ManRegOptDes)
/usr/lib64/libstdc++.so.6: версия `CXXABI_1.3.3'не найдена (требуется /lib/intel/tbb/lib/intel64/gcc4.4/libtbb.so.2)

Можно ли скопировать версии gcc/g++ 4.8 libc.so.6, libstdC++. so.6 в мой каталог пользователя в кластере, чтобы моя программа динамически связывалась с ними? если да, то какую переменную (и) среды я должен установить, чтобы мой исполняемый файл мог динамически связываться с ними?

Благодарю.

Источник

4 ответа

Решение

Вы можете скопировать эти файлы?

Да. Библиотеки объектов - это обычные файлы, как и любые другие. Конечно, вы в конечном итоге захотите подключиться к официальным библиотекам, когда сисадмин сделает их доступными.

Библиотеки объектов представлены в 2 формах....a (архив) и.so (общий объект). Если вы скопируете их в один и тот же личный каталог, компоновщик gcc по умолчанию выберет.so вместо.a.

если да, то какую переменную (и) среды я должен установить [sic]

Я думаю, вам не нужно беспокоиться о стандартных записях LIBRARY_PATH или PATH до тех пор, пока вам не понадобится доставить или пока lib64 не станет "официально" доступной. Труднее распутать временную модификацию пути и т. Д., Чем сделать следующее?

Скопируйте библиотеки, где вы хотите их в свой собственный каталог, возможно

      /home/uname/my_lib64

становление

  • ... / my_lib64 / libc.so.6
  • ... / my_lib64 / libstdC++. So.6

добавлять

  • -L/ дома /uname/my_lib64

в вашей "последней" команде компиляции, чтобы gcc-linker знал, где он может искать библиотеки.

и добавить

  • -lc
  • -lstdC++

в команду 'final', чтобы сообщить gcc-компилятору, какие имена библиотек он должен найти, и найти неразрешенные символы.

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

Я также сделал, и вы можете добавить цель в ваш make-файл, чтобы быть уверенными в том, что.a или.so, на которые вы ссылаетесь, актуальны с библиотеками заголовков, которые вы включаете в свой код. Мой make-файл просто вызвал cp, чтобы поместить последние библиотеки в my_lib64. Координация обновлений библиотек и заголовков - одна из вещей, которую я ожидаю от моего системного администратора, когда они взаимодействуют с моими целями.

Наконец... убедитесь, что заголовочные файлы, которые вы #include, верны. Чтобы проверить, добавьте -H к вашей компиляции и просмотрите имена файлов и пути, запускаемые для чтения в каждой сборке.

Полагаю, это было бы сложнее, но вы можете использовать аналогичный способ обхода тирании sys-admin и скопировать заголовки последних версий в свой собственный каталог. Но теперь ты будешь работать немного усерднее, чем я бы хотел. Как правило, когда вы устанавливаете более новую версию компилятора, он поставляется с соответствующими заголовками и библиотеками.

Удачи.

Источник

Это зависит от того, что позволяет ваш "кластер". Если у вас есть доступ к вашему домашнему каталогу на этих машинах, вы можете использовать среду LD_LIBRARY_PATH найти соответствующие библиотеки.

Источник

Используйте исправления Redhat и внимательно изучите совместимость и требования к вашим последним библиотекам. Это большой список проверок, которым вы должны следовать. Нет короткого ответа будет правильным.

В качестве примера я только что обновил несколько разных серверов Redhat 6.6 и 6.3 / 6.2 / 6.1 до той же версии библиотек glibc и stdC++, которая требуется для компилятора g++ 4.4.7.

Ваш лучший вариант сделать развертывание системного уровня того, что нужно Redhat. Для Redhat 5 использовать более новые библиотеки 4.8 компилятора. - Я настоятельно рекомендую по опыту - забудьте об этом!

Источник

Проверять, выписываться man ld.so для полной информации. LD_LIBRARY_PATH работает очень похоже $PATH делает, но для библиотек. LD_LIBRARY_PATH=/home/user/libraries:/home/user/math_libs:$LD_LIBRARY_PATH может быть все, что вам нужно, когда вы скопируете старые библиотеки.

Но тогда вам, вероятно, понадобятся ВСЕ старые библиотеки, потому что новые будут использовать более новую версию libc/ C++. Проблема в том, что более старая библиотека libc также должна была использовать другое ядро ​​Linux. Таким образом, вы можете получить странные результаты из-за несоответствия системных вызовов.

Источник
Другие вопросы по тегам