|
| |
| 2.6, Pers (??), 23:47, 22/08/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Для настоящих кросс-платформенных решений — надо. К тому же 2.95 вылизан донельзя, и, может, он и не самый быстрый и чего-то не умеет, но он стабильный. gcc 3.x только приближается по качеству и количеству реально поддерживаемых платформ, а про 4-ю версию я вообще молчу. А как ни крути, стабильность для ядра ОС — главное.
Впрочем, я вообще из клана любителей OpenBSD, так что не стоит приниммать мои слова близко к сердцу. ;)
| | |
| |
| |
| 4.16, Andrey Mitrofanov (?), 10:46, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– | |
> всё ж 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 всё не было и не было, но сейчас я его не нашёл.
| | |
| |
| 5.19, gvy (ok), 13:56, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Для тех, кто в те времена таки да, не проявил -- 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 к качеству кода (говорю как майнтейнер более чем полутораста пакетов, которому стонов тоже хватило :) -- пусть лучше компилятор приучает к хоть каким-то правилам и меркам, чем вываливаются вагоны неграмотного кода и неграмотных мэйкфайлов. Тем более неграмотных библиотек.
| | |
| |
| 6.27, Andrey Mitrofanov (?), 18:58, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– | |
> Для тех, кто в те времена таки да, не проявил -- 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 не дождался.
| | |
| |
| 7.29, gvy (ok), 21:10, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>egcs и ко. afair были раньше... в районе 1.1.чего-то
Это egcs-1.1.2 в склерозе застрял ;) Как думаешь -- они от хорошей жизни форкались? Редхаты сделали то же самое, только несколько более успешно.
| | |
|
|
|
|
|
| 2.18, cppmm_ (?), 11:26, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– |
Очень даже нужен gcc второй ветки. Особенно если приходится собирать дрова для старых железок, обновление дров для которых давно не делались. К примеру поддержка TurboCell в карточках orinoco. Такие дрова можно собрать только gcc 2.96. Или, к примеру дрова для мультипортовки MOXA. Та же ситуация.
| | |
| |
| 3.23, Dvorkin (??), 15:59, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >Очень даже нужен 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.31, cppmm_ (?), 16:45, 24/08/2007 [^] [^^] [^^^] [ответить]
| +/– |
С удовольствием бы попробовал, но в наличии только старая железка, которая работала на серваке много лет, но недавно сдох винт. Вот и приходится прикручивать к 4-ому дебиану gcc второй ветки :))
| | |
|
|
|
| |
| |
| 3.21, XimaERA (?), 14:11, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >С тех, как более-менее заработал 4.x на x86*?
С этих пор он не старый, а стабильный. Этак 4.x прекратят поддерживать вообще после первого успешного билда беты 5.x.
| | |
|
|
| |
| 2.8, Dvorkin (??), 02:19, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Лучше пусть сделают, чтобы ядро Linux собиралось Microsoft C :)
боюсь, скоро прийдется сделать так, чтобы Microsoft C мог собирать Linux kernel, а не наоборот :)
| | |
|
| 1.9, pavlinux (??), 03:27, 23/08/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Для ядра 2.6.16+ - gcc-3.4.x
для 2.4.15+ - gcc-2.95.3 (с gcc-3 как-то оно с{т}ранновато себя ведет)
Для приложений не использующих <linux/*.h> и <asm/*.h> - gcc-4.2 самое оно.
Очень шустрые вычисления получаются.
| | |
| |
| |
| 3.11, anonymous (??), 07:03, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– |
В Gentoo /etc/make.conf не исполъзуется для сборки ядра - толъко для ebuild'ов
| | |
| 3.32, 0x00 (?), 02:35, 26/08/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>P.S. Генту несчитается, - там дибилы, у них есть /etc/make.conf
Казнить нельзя помиловать? :))))))
Где в генту дебилы, ась?Вы не ту траву выкурили :)))))
| | |
|
| 2.13, Гость (?), 09:19, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– |
С чего это вдруг "gcc-2.95.3 (с gcc-3 как-то оно с{т}ранновато себя ведет)" ? А дистростроители то и не знали. Странно что вы pavlinux досихпор не работаете на redhat или novell:)
| | |
| 2.14, Гость (?), 09:26, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Для приложений не использующих <linux/*.h> и <asm/*.h> - gcc-4.2 самое оно.
Оно то конечно "оно", но как вы с gcc-4.2 сложные проекты собираетесь собирать на сегодня? С проблемами с линковкой еще не сталкивались? Или binutils последние нестабильные юзаем?
| | |
| |
| 3.17, DeadMustdie (??), 10:49, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >Оно то конечно "оно", но как вы с gcc-4.2 сложные проекты собираетесь собирать на сегодня?
>С проблемами с линковкой еще не сталкивались? Или binutils последние нестабильные юзаем?
Как раз наоборот - для работы с gcc-4.2 нужно брать binutils постарее.
Ибо в старых версиях ld был глюк, которому соответствовал глюк в свежих версиях gcc.
В новом ld глюк исправили, в итоге у людей возникли проблемы - не замеченные некоторыми
тупыми дистростроителями, сложившими в кучку gcc-4.2 и binutils 2.16 :)
| | |
| |
| 4.26, Аноним (-), 18:09, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– |
gcc-4.2 нормально работает начиная с binutils-2.17.50.xx (точно не помню). А если брать постарее чем 2.16 то начинают проблемы вылазить в других местах(не все поддерживается)...
Пока выход один - держать 3 компилятора(4.1.2,3.4.6,4.2.1) за место двух.
| | |
|
|
|
| |
| 2.30, pavlinux (??), 22:00, 23/08/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Как! Вы еще не пробовали компилять с Intel C/C++???
Так вперёд:
cat Makefile | sed -e s/"gcc"/"icc -gcc-version=340"/g > Makefile.new
cat Makefile.new > Makefile
| | |
|
|
