В списке рассылки разработчиков Linux ядра рассматривается вопрос (http://kerneltrap.org/node/14213) о прекращении поддержки сборки ядра устаревшими версиями gcc (ниже версии 4.0). Сейчас в ядре осуществляется поддержка 6 веток gcc. По мнению Linus Torvalds сокращать число поддерживаемых версий gcc можно только в крайнем случае, когда нет другого выхода.URL: http://kerneltrap.org/node/14213
Новость: https://www.opennet.ru/opennews/art.shtml?num=11784
И я думаю Линус прав...
сомневаюсь, что кому-то сильно необходим gcc 2.x
Для настоящих кросс-платформенных решений — надо. К тому же 2.95 вылизан донельзя, и, может, он и не самый быстрый и чего-то не умеет, но он стабильный. gcc 3.x только приближается по качеству и количеству реально поддерживаемых платформ, а про 4-ю версию я вообще молчу. А как ни крути, стабильность для ядра ОС — главное.Впрочем, я вообще из клана любителей OpenBSD, так что не стоит приниммать мои слова близко к сердцу. ;)
наверно всё ж 2.96
> всё ж 2.96Для тех, кто в те далёкие времена :-P под стол пешком^W^Wне проявил любознательности... ;-) ==> http://gcc.gnu.org/gcc-2.96.html
Последний "родной" gcc - что-то типа 2.95.4 + несколько патчей из CVS (что-то вроде http://packages.debian.org/src:gcc-2.95 )
См.также google.ru, искать (gcc 2.95.4 2.96), (gcc 2.96 site:lwn.net), (gcc 2.96 site:kerneltrap.org) и пр.
Где-то был более подробный рассказ о том, как RH "выпустила" 2.96 без участия его "родителей", потому как торопилась к своему релизу, а официального 2.95+1 всё не было и не было, но сейчас я его не нашёл.
Для тех, кто в те времена таки да, не проявил -- gcc steering committee без проектов вроде egcs/pgcc и вендоров вроде Cygnus и Red Hat до сих пор бы чесался-вылизывался над 2.95, небось.И при всей моей неприязни к _продуктам_ вроде Red Hat Linux x.0 и Fedora -- это когда на пользователей вытряхивается откровенно сырой код -- зато потом обтаптываемые грабли уже не включены в x.1 и на x.2 совсем можно работать (если в нумерологии RHL, федоры это касается лишь отчасти и с учётом updates в десятки _гигабайт_ на выпуск). Просто это лучше знать и не наступать на грабли почём зря, если не предполагается писать багрепортов.
Опять же при всех вздохах и стонах насчёт повышения требований gcc 3.x/4.x к качеству кода (говорю как майнтейнер более чем полутораста пакетов, которому стонов тоже хватило :) -- пусть лучше компилятор приучает к хоть каким-то правилам и меркам, чем вываливаются вагоны неграмотного кода и неграмотных мэйкфайлов. Тем более неграмотных библиотек.
> Для тех, кто в те времена таки да, не проявил -- gcc steering committee без проектов вроде egcs/pgcc и вендоров вроде Cygnus и Red Hat до сих пор бы чесался-вылизывался над 2.95, небось.egcs и ко. afair были раньше... в районе 1.1.чего-то [или нет, спасибо склерозу]
Про "чесался бы" и вендоров -- не знаю, не в курсе.
Спасибо за взгляд под таким углом.Ой, egcs слился не в 1.1...., а как раз-таки в 2.95:
"""after a long period of behind-the-scenes negotiation, EGCS and GCC reunited, and EGCS was accepted as the GNU Project's official GCC. At that time, GCC was renamed from "GNU C Compiler" to "GNU Compiler Collection", which conveniently has the same acronym. The first compiler version released after the reunification was GCC version 2.95.""" http://gcc.gnu.org/wiki/HistoryВидимо, выход 3.0 как раз и был задержан тем "long period of" и переходом с кафедрала на базар.... RH не дождался.
>egcs и ко. afair были раньше... в районе 1.1.чего-тоЭто egcs-1.1.2 в склерозе застрял ;) Как думаешь -- они от хорошей жизни форкались? Редхаты сделали то же самое, только несколько более успешно.
Очень даже нужен gcc второй ветки. Особенно если приходится собирать дрова для старых железок, обновление дров для которых давно не делались. К примеру поддержка TurboCell в карточках orinoco. Такие дрова можно собрать только gcc 2.96. Или, к примеру дрова для мультипортовки MOXA. Та же ситуация.
>Очень даже нужен gcc второй ветки. Особенно если приходится собирать дрова для
>старых железок, обновление дров для которых давно не делались. К примеру
>поддержка TurboCell в карточках orinoco. Такие дрова можно собрать только gcc
>2.96. Или, к примеру дрова для мультипортовки MOXA. Та же ситуация.насчет turboCell не знаю, а вместо мультипортовки МОХА можно с успехом использовать DS*/EM* девайсы от Tibbo Tech. см. http://tibbo.com/
кстати, поддерживает Линукс 2.2.x, 2.4.x, 2.6.xкстати, ума не приложу, почему это МОХА нельзя свежим gcc. у них же драйвер в исходники ядра включен! должен собираться. или не следят за своим детищем? :) я, например, регулярно делаю апдейты. попробуйте Tibbo ;)
С удовольствием бы попробовал, но в наличии только старая железка, которая работала на серваке много лет, но недавно сдох винт. Вот и приходится прикручивать к 4-ому дебиану gcc второй ветки :))
Речь идет о версиях ниже 4.0
Положительно, для любителей "интима" со сложным железом, новость крайне приятная.
Нет, вы меня простите, но с каких пор gcc 3.x - старый?!
С тех, как более-менее заработал 4.x на x86*?
>С тех, как более-менее заработал 4.x на x86*?С этих пор он не старый, а стабильный. Этак 4.x прекратят поддерживать вообще после первого успешного билда беты 5.x.
Лучше пусть сделают, чтобы ядро Linux собиралось Microsoft C :)
>Лучше пусть сделают, чтобы ядро Linux собиралось Microsoft C :)боюсь, скоро прийдется сделать так, чтобы Microsoft C мог собирать Linux kernel, а не наоборот :)
Для ядра 2.6.16+ - gcc-3.4.x
для 2.4.15+ - gcc-2.95.3 (с gcc-3 как-то оно с{т}ранновато себя ведет)Для приложений не использующих <linux/*.h> и <asm/*.h> - gcc-4.2 самое оно.
Очень шустрые вычисления получаются.
P.S. Генту несчитается, - там дибилы, у них есть /etc/make.conf
В Gentoo /etc/make.conf не исполъзуется для сборки ядра - толъко для ebuild'ов
Сам дебил, прогрес глаза режет, или зависть заела?
>P.S. Генту несчитается, - там дибилы, у них есть /etc/make.confКазнить нельзя помиловать? :))))))
Где в генту дебилы, ась?Вы не ту траву выкурили :)))))
С чего это вдруг "gcc-2.95.3 (с gcc-3 как-то оно с{т}ранновато себя ведет)" ? А дистростроители то и не знали. Странно что вы pavlinux досихпор не работаете на redhat или novell:)
>Для приложений не использующих <linux/*.h> и <asm/*.h> - gcc-4.2 самое оно.Оно то конечно "оно", но как вы с gcc-4.2 сложные проекты собираетесь собирать на сегодня? С проблемами с линковкой еще не сталкивались? Или binutils последние нестабильные юзаем?
>Оно то конечно "оно", но как вы с gcc-4.2 сложные проекты собираетесь собирать на сегодня?
>С проблемами с линковкой еще не сталкивались? Или binutils последние нестабильные юзаем?Как раз наоборот - для работы с gcc-4.2 нужно брать binutils постарее.
Ибо в старых версиях ld был глюк, которому соответствовал глюк в свежих версиях gcc.
В новом ld глюк исправили, в итоге у людей возникли проблемы - не замеченные некоторыми
тупыми дистростроителями, сложившими в кучку gcc-4.2 и binutils 2.16 :)
gcc-4.2 нормально работает начиная с binutils-2.17.50.xx (точно не помню). А если брать постарее чем 2.16 то начинают проблемы вылазить в других местах(не все поддерживается)...
Пока выход один - держать 3 компилятора(4.1.2,3.4.6,4.2.1) за место двух.
лучшеб сделали поддержку icc
Как! Вы еще не пробовали компилять с Intel C/C++???Так вперёд:
cat Makefile | sed -e s/"gcc"/"icc -gcc-version=340"/g > Makefile.new
cat Makefile.new > Makefile
ХЗ чего ето, но наверно, что-то очень хорошее. В винду его скорее.
icc - intel c compiler