Как сейчас принято ставить древние версии gcc на современный линукс

А gcc 5.4 не может собрать 3.2?

Что значит «принято»? Это не принято. Необходимость в этом сама по себе признак профнепригодности. Зачем может понадобиться код четвертьвековой давности? Если он и правда нужен, почему его не актуализировать для сборки в актуальных окружениях?

Я такой вопрос решил для себя виртуалкой с древним образом RHEL или RHL.

Где-то у меня были образы с GCC 3.3 или GCC 2.95, не помню где какой, но если интересно – качай, запускай в VirtualBox, смотри:

• https://files.exlmoto.ru/linux/Red_Hat_Enterprise_Linux_4.8.ova (755 MB)
• https://files.exlmoto.ru/linux/Red_Hat_Linux_7.3_Valhalla.ova (535 MB)

Удачи.

всегда можно взять Slackware подревнее и в нём собрать :-)

почти наверняка можно взять из него пакеты gcc и поместить в chroot или даже просто отдельную иерархию. Там пакеты это архивы - gz, xz без лишних наворотов.

Надо взять виртуалку и запустить древний GCC в ДРЕВНЕМ линуксе.

LFS. Сборка (кросс) тулчейна.

Можно попробовать обратный бутстрап сделать. Ставим самую старую версию, которая ставится, в ней собираем самую старую, которая собирается и тд. Но могут проблемы с окружением вылезти. С glibc, с другими библиотеками, их все тоже надо собирать свои и потом подсовывать.

// Сам бутстрапил вверх, назад не пробовал

Это боль. Новые GCC+ко не умеют собирать старые GCC+ко. Дикая проблема buildroot и т.п..

• Самое простое виртуалка.
• Можешь попробовать старый Debian запустить в докере. Старые редхады могут не запуститься в докере.
• отыскать собранный tool chain
• собрать в старом окружении старый crosstool-ng и использовать его на новой системе

Зачем может понадобиться код четвертьвековой давности?

Вот не поверишь, чтобы изменить одну константу в софтине, которая работает уже 25 лет и при этом уже на более-менее свежем дебиане. Тут рядом еще 16-битные экзешники для офтопика используют, но слава богу не хотят их изменять.

14й не собрал 5.4, а на 5.4 не пробовал.

Всем спасибо, видимо виртуалка все же мой путь.

из репозиториев https://build.opensuse.org/package/show/devel:gcc/gcc33

можно попробовать взять все эти патчи собрать самому

Так это, в бинаре поменяйте.

В NixOS самая древняя версия сейчас 6.5.0, но можно легко добавить и более старые.

Если одну константу поменять, то может самое простое - это ничего не компилировать, а пропатчить исполняемый файл. Ищешь в hex-редакторе эту константу (с учётом порядка байт) и меняешь. Если что-то не то поменял и вариантов присутствия много, меняешь в другом месте

В чём проблема просдо сделать chroot?

С таким же успехом можно пробовать собирать из дебиановских сырцов.

А если потом надо будет функцию добавить или что-то еще по мелочи поправить? Я понимаю, что наиболее правильное решение переписать под свежий gcc, но тут нужен кто-то с более высокой квалификацией.

Я не предполагал, что кроличья нора настолько глубока, что виртуалка, чрут и докер будут наиболее лёгким решением.

ЯННП, сабж есть в дебиановских репах? Или из каких сырцов?

сабж есть в дебиановских репах

Всегда был со времён сарджа, что ли. Я про то, что патчи для sle10, который немного устарел. Не так сильно конечно, но равно уже древность.

Там Factory же, те то, что в снапшоты Tumbleweed идёт.

SLE10 в описании пакета как было - так и осталось.

А, ну тогда можно и попробовать, спасибо.

https://github.com/crosstool-ng/crosstool-ng/tree/master/packages/gcc можно собрать 4.9.4

Лучше скажи зачем? Что в нём есть такого, чего выпилили из новых версий?

А вообще если прямо действительно нужно, то для таких динозавров я бы взял виртуалку тех лет и не засорял рабочую систему.

пусть будет версия 3.2

А tcc не скомпилирует? Или zig, или cparser из libfirm. :)

Я бы в докере поставил. Думаю, это проще всего будет.

А если с помощью debootstrap развернуть древний Linux в chroot ?

Докер, виртуалка … какой-то дикий оверинжениренг Chroot!

chroot это элементарное решение. мы не в винде, парень, у нас уже всё есть :)

GCC+ко не умеют собирать старые GCC+ко

А отчего так? Не следовали стандартам & напихали несовместимых расширений?

Не. Просто измазали исходники компилятора убогим autotools-калом, который рассыпается на современных системах.

Будто разрабы кала это не те же разрабы, что придумали gcc.

Что в нём есть такого, чего выпилили из новых версий?

Хз, но на свежем gcc не собирается, на более древнем тоже, но ошибок меньше.

не засорял рабочую систему.

Собрать в каталоге пользователя, вай нот?

какой-то дикий оверинжениренг

Все что тащит за собой систему это оверинжениренг, chroot туда же, так ещё и права рута требует.

Все есть, но как то не всё. Компилятор vb6 спокойно ставится и работает в том же офтопике. А древняя gcc ставится нетривиально и требует поставить половину старой системы. Уменьшение системного раздела на лету, без размонтирования ext4 не умеет, в отличие от ntfs в офтопике.

P.S. не думал, что буду защищать офтопик. Что дальше, резиновые женщины?))

Хз, но на свежем gcc не собирается,

Ты покажи ошибки хоть и скажи на чём проект, на C или C++? Может быть банальным -fcommon всё разрешится.

В оффтопике свои проблемы, местами и похуже, да. Чего только стоит что они умудрились сделать utf16-le основной системной кодировкой. Я вот только сегодня узнал — думал оно там только в кишках там, а оказалось что прямо таки в пользовательском окружении.

В оффтопике свои проблемы

При работе с офтопиком, я матерюсь гуще и чаще, раз в 10.

Потому что в венде 800 гигабайт либ совместимости. А здесь их таскать не надо, потому что можно просто чрутануться

А древняя gcc ставится нетривиально и требует поставить половину старой системы.

Энжой ё so hell.

Кстати, сам gcc еще с древности прекрасно умеет работать из рандомного каталога, не привязываясь к системным или вкомпилированным путям, и ничего не мешает делать портабельные сборки. Просто не принятой линуксовой культурой разработки.

Может быть банальным -fcommon всё разрешится.

А может не решиться. Если у него древний софт в продакшене, который потребовалось запатчить, то самое разумное — воспроизвести новый билд в виртуалке или чруте в той же среде, что собирался предыдущий билд.

А то если на новой ОС что-нибудь скопилируется, но не заработает корректно, проблема может выявиться потом внезапно.

Опытным путём выяснилось, что собирается с помощью gcc-4.9 из jessie.

На 5.4 и выше ошибка:

error: invalid use of incomplete typedef ‘WINDOW’ {aka ‘struct _win_st’}
  562 |             maxy=win->_maxy - 1;

Почему docker считаешь излишним? Никакого оверхеда.

Опытным путём выяснилось, что собирается с помощью gcc-4.9 из jessie. На 5.4 и выше ошибка

Тогда наиболее вероятно, что дело в стандарте языка по-умолчанию (опиция -std=). В старых версиях дефолты были c89 и c++98, потом это меняли.

Я же в своё время сталкивался с другим случаем: старый проект был написан под g++ 3.x, а под 4.х собираться отказывался, так как в коде было полно нарушений стандарта, которые 3.х разрешал, а 4.х уже нет. И внутри серии 4.0—4.9 тоже шло послежовательное ужесточение следования стандартам, хотя уже не настолько радикальное.

Некоторые люди делают портабельные сборки gcc, например тут (github.com). Но для 3.2 ты вряд ли что-то найдёшь, его даже непортабельно собрать на современной системе — это очень сложный многостадийный квест.

Классические неосиляторы же. Я не понял, значит не нужно.

Может запилишь ликбез?

Опция опиция -std=89 уже стоит в Майкфайле, не помогла как и -fcommon.

Как выяснил, собирается на версии 4.9.

Просто не принятой линуксовой культурой разработки.

Кросс-тулчейны очень часто в виде портабельных сборок распространяются.