Компиляция с недавним GCC на RHEL6: Как распространять программное обеспечение?
Мое программное обеспечение компилируется на различных ОС, включая RHEL7. У меня есть просьба собрать его для запуска на RHEL6. Моя проблема в том, что мой код C ++ во многом опирается на функции C ++ 11, которых нет в gcc-4.4, который поставляется с RHEL6.
Я видел, что есть способы иметь более свежие версии gcc для запуска на RHEL6, такие как Developer ToolSet, например. Я не сомневаюсь, что смогу собрать свое программное обеспечение для RHEL6.
Тем не менее, после компиляции, скажем, с gcc-6, что я должен буду предоставить с двоичными файлами моего программного обеспечения? Библиотека C gcc-6? Библиотека C ++ gcc-6? Должен ли я вместо этого связать их статически с моим двоичным файлом?
Кроме того, для RHEL мое программное обеспечение упаковано в файлы .rpm и устанавливается в стандартные каталоги: / usr / bin, / usr / lib … Где бы я мог установить эти новые файлы библиотек C и C ++ в целевой системе ? (Очевидно, не в / usr / lib, где они могут мешать настройкам по умолчанию!)
Редактировать: Мое программное обеспечение является общим объектом, я думаю, я могу статически связать библиотеку C ++? Но как насчет программы (я не контролирую ее), которая будет использовать мой общий объект. Может ли он использовать другую версию библиотеки C ++? Разве компоновщик не найдет много дубликатов? Похоже, я бы открыл банку с червями …
Редактировать: Можно ли будет использовать более свежий компилятор gcc со стандартной библиотекой C ++ стандартной библиотеки RHEL6?
Решение
Вы можете распространять свое приложение вместе с соответствующей динамически связанной версией стандартной библиотеки C ++. Вам не нужно помещать его в / usr / lib, но вы должны связать свое приложение таким образом, чтобы оно нашло правильную версию библиотеки (см. Параметр -rpath для компоновщика).
Кроме того, вы должны убедиться, что ваше приложение не использует новые функции glibc (или же поставьте соответствующую версию glibc вместе с приложением). Самый простой способ убедиться в этом — собрать все (приложение и новый gcc) на основе более старой версии glibc. И самый простой вариант выполнения тот это построить на более старой версии ОС (но с новым компилятором).
Другие решения
Статическое связывание вашего бинарного файла со стандартной библиотекой — определенно самое простое решение. Потенциальные проблемы:
- Затем вы становитесь ответственным за выпуск новой версии вашего приложения, когда в одной из библиотек обнаружена уязвимость (а не пользователи несут ответственность за исправление библиотек в своей системе).
- Это действительно работает, только если все связан вместе в один двоичный файл. Если ваше приложение в настоящее время упаковано как серия различных общих объектов, вам не нужно, чтобы библиотека времени выполнения была статически связана с каждым.
Как Квантовый физик примечания в комментарии, контейнерные решения, такие как докер также может быть хорошим (и простым в обслуживании) решением.
Решение общей проблемы упаковки новой версии библиотек времени выполнения с вашим приложением — гораздо более интересный вопрос, и, надеюсь, кто-нибудь скоро объяснит, как это сделать.
FYI — WRT Developer Toolset, если вы скомпилируете его на RHEL 6, он будет работать как на RHEL 6, так и на 7.