Риски разных версий GCC при ссылке / времени выполнения?
Я использую компилятор Intel C ++, который в Linux использует GNU-библиотеки libc.so и libstdc ++.
Вот моя проблема. Чтобы получить доступ к некоторым новейшим функциям C ++ 11, мне нужно использовать libstdc ++, который поставляется с GCC 4.7 или выше. Но я застрял с использованием CentOS 6.4.
На CentOS 6.4 нативная версия GCC — 4.4. Но используя RedHat с именем «SCL» и пакетом с именем «devtoolset-1.1», я могу установить GCC 4.7 в «/ opt».
Я настроил вещи так, чтобы они использовали GCC 4.7 описанным выше способом, я могу использовать более новые функции C ++ 11.
Итак, вот мой вопрос: если пользователь запускает мою программу только с версиями libc.so / libstdc ++. GCC 4.4, поэтому в пути к библиотеке существует риск, что моя программа будет иметь ошибки из-за некоторого несоответствия между версиями 4.4 и 4.7. из этих библиотек?
Если есть потенциальная проблема, могу ли я обойти ее, статически связывая в GCC 4.7 версии libc и libstdc ++? Или это настраивает себя на другие проблемы, если / когда другие библиотеки, которые мой код динамически загружает, принимают более старую версию libc / libstdc ++, поставляемую общесистемным пакетом GCC 4.4?
Решение
Как отметил преториан в комментариях ниже, использование devtoolset фактически решает проблему, которую я первоначально описал в этом ответе. Я исправил ответ.
есть ли риск, что в моей программе будут ошибки из-за несоответствия между версиями этих библиотек 4.4 и 4.7?
Да. Связывание с более новой версией libstdc ++., А затем попытка запустить новую и более старую версию не поддерживается на 100%. Если какой-либо объект в вашей программе или библиотеках, которые он использует, скомпилирован с GCC 4.7 и связан с libstdc ++. так с 4.7 тогда вам нужно использовать libstdc ++. так от 4.7 (или новее) во время выполнения. Вероятно, он даже не запустится, но если это произойдет, могут быть тихие ошибки из-за несовместимости. Но это не проблема в вашем случае, потому что вы не ссылаетесь на libstdc ++ в GCC 4.7, поэтому смотрите ниже.
можно ли обойти это, статически связывая в GCC 4.7 версии libc и libstdc ++?
1) Вам нужно будет сделать это только для libstdc ++, потому что не существует такой вещи, как «версия libc для GCC 4.7». Glibc — это совершенно отдельный проект от GCC. Когда вы используете GCC 4.7, вы не используете другой libc, вы все еще используете системный libc из CentOS 6.4.
(Кроме того, имейте в виду, что статически связывающий glibc настоятельно рекомендуется сопровождающими glibc, и некоторые функции glibc не будут работать при статической связи.)
2) Статическое связывание libstdc ++ обойдёт проблему, но вам это не нужно, потому что это то, что Red Hat Developer Toolset (devtoolset) делает для вас все равно. Весь смысл devtoolset в том, что он позволяет вам использовать более новый GCC и более новую libstdc ++, но без создания каких-либо зависимостей во время выполнения от более новой библиотеки libstdc ++. Скомпилированные исполняемые файлы нуждаются только в системной версии libstdc ++., Так что она всегда присутствует в RHEL / CentOS, даже в системах без установленного devtoolset. (Что делает devtoolset, так это упаковывает все новые функции libstdc ++ в статическую библиотеку, которая называется libstdc++_nonshared.a так что все части, отсутствующие в системе libstdc ++. статически связаны друг с другом, а все остальное будет происходить из системы libstdc ++.
Если бы вы не использовали devtoolset, то вместо статической компоновки libstdc ++ был бы другой вариант — доставить более новую версию libstdc ++. То есть с вашим кодом и убедиться, что он найден первым (например, связав код с RPATH, который ссылается на более новую libstdc ++. ). Но с devtoolset это не обязательно.
Или это настраивает себя на другие проблемы, если / когда другие библиотеки, которые мой код динамически загружает, принимают более старую версию libc / libstdc ++, поставляемую общесистемным пакетом GCC 4.4?
При использовании devtoolset таких проблем не будет, потому что вы всегда используете более старую версию libstdc ++, и поэтому никогда не возникает конфликта.
Другие решения
Других решений пока нет …