Comments 28
Какие-то у вас решения из разряда битв с ветряными мельницами.
1. Если вам так хочется самим рулить версиями пакетов — возьмите gentoo|arch, будут вам на выбор gcc от 6.5 до 11.0 и без танцев с бубном. Все патчи предоставит дистрибутив.
2. Ну или по современному — делайте сброку в докер контейнере. Благо у gcc есть официальные образы с версиями от 8 и выше. Тогда сменить версию можно будет поменяв пару цифр в пайплайне сборки приложения.
1. Если вам так хочется самим рулить версиями пакетов — возьмите gentoo|arch, будут вам на выбор gcc от 6.5 до 11.0 и без танцев с бубном. Все патчи предоставит дистрибутив.
2. Ну или по современному — делайте сброку в докер контейнере. Благо у gcc есть официальные образы с версиями от 8 и выше. Тогда сменить версию можно будет поменяв пару цифр в пайплайне сборки приложения.
Gentoo не вполне соответствует корпоративным представлениям о стабильности, требуемой для продуктивных решений. Ну а сборка в докере у нас тоже есть. Просто не везде докер хорошо подходит, особенно когда требуется выжать из железа все соки.
Просто не везде докер хорошо подходит, особенно когда требуется выжать из железа все соки.
Какие ещё соки? Контейнеры это просто средство изоляции, там нет никаких абстракций дополнительных от железа.
Накладные расходы на виртуализацию все равно есть. А ещё бывают нюансы с доступом ко всяким там железкам из контейнера. Это мы, впрочем, уже победили )
Контейнеры не средство виртуализации, там нет никакого гипервизора. По сути это chroot на стероидах.
Сеть и доступ к файлам там таки виртуализируются — со всеми вытекающими. Да, это не то же самое что и в KVM, но всё равно накладные расходы есть, и они очень ощутимы если очень много ввода-вывода (с сетью или файлами), особенно если это всё крутится на недоверенной системе со всеми примочками против спектра и компании, и особенно если этих контейнеров много на одной железке.
scl enable gcc-toolset-9
чем не угодил?
чем не угодил?
Можно было взять готовый gcc-9.3.1 src.rpm из Fedora, и пересобрать его.
Полумертвый дитрибутив, поддержку которого вот-вот прекратят, извращения с натягиванием совы на глобус, когда в нормальных дистрибутивах можно использовать gcc 10-11 со всеми его преимуществами и багфиксами, и поддержкой новых процессоров.
Вот когда CUDA Toolkit научится работать с gcc 10-11, тогда и будем использовать ) Что до смерти дистрибутива — ну так описанный подход можно и на RHEL использовать, а он помрет не так скоро.
my2coins работает aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cuda-11.0
Как зависимость стоит системный gcc 10.2 без указания 9й версии. К примеру тут наоборот gcc 8 aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cuda-10.2
Вы вероятно используете инсталер под дистрибутив, отсюда не совместимость, у нас же обычно все пакеты с убунты берутся и распаковываются, и подменяются библиотеки на системные. К примеру если удалить libstdc++.so libstdc++.so.6 идущие с пакетом от другого дистрибутива, то решается большая часть глюков, и приложения подхватываются системную библиотеку. Например я их удаляю в Matlab и Intel Quartus.
А у меня AMD видео и процессор, и наоборот llvm и gcc новые дают хорошую прибавку скорости.
Как зависимость стоит системный gcc 10.2 без указания 9й версии. К примеру тут наоборот gcc 8 aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cuda-10.2
Вы вероятно используете инсталер под дистрибутив, отсюда не совместимость, у нас же обычно все пакеты с убунты берутся и распаковываются, и подменяются библиотеки на системные. К примеру если удалить libstdc++.so libstdc++.so.6 идущие с пакетом от другого дистрибутива, то решается большая часть глюков, и приложения подхватываются системную библиотеку. Например я их удаляю в Matlab и Intel Quartus.
А у меня AMD видео и процессор, и наоборот llvm и gcc новые дают хорошую прибавку скорости.
Спасибо за хорошую новость, я этот момент упустил ) Но нам не поможет, потому что есть ещё всякие хитрые библиотеки в стеке, которые как раз требуют gcc не выше 9.
my2coins это тоже не проблема в большинстве случаев, многие библиотеки можно подменить на новые, в большинстве случаев API у них не меняется. К примеру для для поддержки API ncurses-5, если у вас стоит ncurses-6 есть такая штука aur.archlinux.org/packages/ncurses5-compat-libs
К примеру системный zlib у меня заменен на более быстрый zlib-ng.
На моей памяти обычно вся не совместимость решается просто удалением libstdc++.so libstdc++.so.6 libncurses++.so* libncurses.so* идущие в составе пакета, дальше приложение при запуске не находит их и берет просто системные.
К примеру системный zlib у меня заменен на более быстрый zlib-ng.
На моей памяти обычно вся не совместимость решается просто удалением libstdc++.so libstdc++.so.6 libncurses++.so* libncurses.so* идущие в составе пакета, дальше приложение при запуске не находит их и берет просто системные.
Это вам пока что везёт ) Однажды удаление libstdc++ может дать интересные спецэффекты в силу разных версий ABI, например
my2coins не только мне, а еще тысячам людей, метод не мною придуман. Я такого уже как лет 10 не помню, раньше да все ломалось при замене. Разработчики не дураки, чтобы таблицу экспорта функций портить. Любая библиотека имеет таблицу экспорта функций и чаще всего обратную совместимость со старыми версиями. Кучу библиотек системных взаимозаменяемы, например libjpeg, libjpeg-turbo, mozjpeg — можно поставить любую из трех и ничего не сломается. На моей памяти практически не было, чтобы прям жестко что-то ломали без возможности исправить. Наоборот при использовании libstdc++.so идущим с пакетом чаще всего происходит то, что он там чего-то не может найти в libstdc++.so, например версия glibc отличается, и приложения криво работают, при этом сыпет кучу ошибок в консоль. Стоит удалить libstdc++.so* как все ошибки уходят и в приложении все функции начинают нормально работать. В этом и отличие меня и вас, вы используете Centos и видимо не много собираете пакетов из исходников, а у меня Arch Linux, даже если что-то сломается, то можно быстро пересобрать, но такое довольно редко. На будущее если хотите что-то собрать из исходников, то ищите пакеты aur.archlinux.org, смотрите исходники пакетов в arch archlinux.org/packages/core/x86_64/gcc сбоку есть ссылка source files, посмотрите пакеты gentoo packages.gentoo.org/packages/sys-devel/gcc и откройте последнюю версию Linux From Stratch www.linuxfromscratch.org Ваша статья довольно низкого уровня, и все ваши страдания уже давно решены и описано решение по выше указанным ссылкам.
У меня как раз разработчики нарывались на несовместимость ABI (правда, не у нас, а на предыдущем месте работы), теперь относятся к этому с повышенным вниманием )
my2coins люблю на свежем софте работать, по мне он обычно стабильный, и даже если что-то ломается, то быстро можно патчи через git подтянуть. Например сегодня собрал mesa-21.1.0-rc2, с исходников из архива на сайте не собиралось, подтянул патч собрал, как итог плюс к производительности на видеокарте amd, в другом приложении maintainer олень например сломал пакет в archlinux, и сразу пустил без теста 3 приложения, у всех coredump при запуске, отправил багрепорт ему, и скачал патчи, собрал их у себя, все работает.
кстати с обновлением компилятора в fedora вроде был прикол: при сборке ядра свежим gcc приехали ошибки, вроде bcache пострадал
Oakum в Arch Linux все нормально, собираются нормально 5.11.15, 5.11.16, сейчас перешел на 5.12-rc8 все нормально пашет и собирается. Ядро, mesa у меня каждый релиз собираются в ручную т.к. видео карта у меня AMD новой серии и с каждым релизом улучшается ее поддержка. Все собирается с оптимизацией и патчами под zen2. Отклик системы значительно выше, чем дистрибутивных ядер и mesa. Вот только что собрал mesa 21.0.3 вышедшую час назад, все хорошо. Если что-то ломается, проблема скорее всего не в компиляторе, а просто компилятор собран криво. В компиляторах есть специально тесты, чтобы ничего не ломать с новым релизом.
Не multilib, а multiarch. Я не знаю, как там в ваших быстродохнующих центосях, а в дебиан мультиарч контролируется тривиально с помощью dpkg.
$ dpkg --print-foreign-architectures
i386
$ dpkg --print-architecture
amd64Заметим, включение этой штуки — осмысленное деяние во имя стима (на моём десктопе), и выключение довольно тривиально.
В целом, вся возня в районе спеков у меня всегда вызывала повышенную брезгливость. Какое-то оно уродливое, в сравнении в debian/rules. При том, что к оному rules претензий выше крыши, с инженерной точки зрения оно куда более элегантное.
а чем вариант собрать gcc с помощью crosstool-ng не устроил?
Интересно, а подошли бы контейнеры для решения вашей задачи? Я имею в виду не сборку компилятора, а сборку кода внутри контейнера, который бежит на centOS8. В этом контейнере можно установить gcc нужной версии и артефакты сборки класть куда надо.
Sign up to leave a comment.
Будни DevOps: cобираем gcc 9.3.1 под CentOS 8