Только вот на машине с Solaris версии 2.6
он без пакета GNU binutils не собирается
(видимо ему не нравится нативный ассемблер).
А на Solaris 2.7 обновление с gcc-2.95 до 3.0.1 и больше
вообще без вопросов идёт.
Вот подожду, как утихнут скачивания с ftp зеркал - и сам его
поставлю.
Интересно вот только, почему в Линуксе дистры
Redhat-клоны и Madrake с ними же - используют
свой gcc-2.96, которого на GNU.org и в помине нет?
2Android: А ты поставь и поиграйся с ними. У RH кстати в пакете gcc-3.0.1 лежит снепшот GCC 3.0.2 с патчами.
У RedHat'а технология такая. Если они чуствуют, что текущий снепшот близок к релизу они запихивают его в пакет наложив нужные на их взгляд патчи. Если в релизе фиксятся баги то они выпускают апдейт пакета с пофикшеными багами. Таким образом их дистибутив успевает вовремя за обновлением версий. Пользователям только нужно вовремя обновлять пакеты. А они на этом деньги зарабатывают.
С 2.96 они просчитались. Но не в плане надежности а в плане политики.
Расскажите как правильно апгрейдить gcc !
Сейчас RH 7.1 gcc 2.96.81 хочу gcc 3.0.3
Нужно безболезненно апгрейдить, как это сделать? Если не трудно, то как можно подробней расскажите.
Ядро нормально собиралось еще gcc-3.0.2 (у меня, по крайней мере), а вот с компиляцией XFree86 были проблемы. Интересно, может у кого-нибудь получилось собрать XFree-4.1.0 gcc-3.0.2? А заодно, может кто знает когда планируется выход XFree-4.2.0? А то я замучался со своим Radeon-7500 - в версии 4.1.0 под него драйвера нет, а бета, взятая с CVS, увы gcc-3.0.2 так и не собралась :-( Может кто что посоветует?
>а бета, взятая с CVS, увы gcc-3.0.2 так и не собралась :-( Может кто что посоветует?
Ну на самом деле та бетта намного лучше стабильной 4.1.0 - я сам юзаю только X11-CVS
На счет gcc-3.0.x ничего сказать немогу хотя у меня установлено 5 gcc компилеров -
просто не компилил.
>Интересно, может у кого-нибудь получилось собрать
>XFree-4.1.0 gcc-3.0.2? А заодно, может кто знает когда
>планируется выход XFree-4.2.0?
у меня тоже не получилось.
Выход хфрии 4.2 должен был быть в конце ноября. На сайте глаголят, что хфрии задерживается на несколько месяцев. Точную дату сказать не могут.
2berry: Трудно сказать. Вероятно они считают, что он близок к релизу. Или просто заранее готовятся. Номер rpm-билда 0.1 о многом говорит. Я подозреваю, что хотят его в 8.0 запихнуть. Они gcc-2.96-101 в компат запихнули (Падлы. Только скачаный у меня остался. Теперь придется его вручную домой нести). Значит основным будет третий. И скорее всего 3.1.
Сегодня собрал свой проект на C++ под ним - время сборки, правда
мне показалось чуть больше (но это субъективно, т.к. на машине работаю
не я один). Вроде повторная компиляция после редактирования одного
файла оказалась быстре.
Никто не знает, сделали ли они там в g++ механизм инкрементальной
компиляции, о котором так много говорил доктор Страуструп?
А из дистров линукса, где это стоит собирать - думаю Слака больше
всего подойдёт. Эта ситстема наиболее приближена к идее "дистрибутива
с нуля" (linuxfromscratch.org), в ней используются оригинальные gcc
и библиотеки, а не патченные продукты аля egcs или gcc-2.96.
Только обязательно ставтье новый компилер в другое
место, чем тот которым вы инсталлируемый собирать будете - иначе при
сборке он запутается, и у вас получится "разбитое корыто": старый
угробите, а новый работать не захочет.
Для этого лучше использовать опцию --prefix=/usr/local или --prefix=/opt
если исходный компилер у вас стоит в /usr.
И не забудтье отредактировать файл /etc/ld.so.conf на предмет путей
к библиотекам, идущим с этим компайлером и запустить после этого
ldconfig.
Подробнее про установку компайлера gcc по-русски читайте здесь:
Какая текущая версия слаки и чем там собраны все
двоичные библиотеки и приложения?
2 anonymous (*) (2001-12-26 22:09:48.0):
Про инкрементальную компиляцию я прочитал в переводном третьем издании
книги Б. Страуструпа "Язык программирования С++". Суть в том, что при
традиционнном способе перекомпиляции программы на C++, при изменении
всего одного файла будет, помимо прочего, перекомпилирован весь код
подключаемый директивами "#include", а в C++ (в отличае от C) - там
может содержаться море кода, особенно при использовании шаблонов,
которых туева хуча, например, в стандартной библиотеке STL. В этих
файлах при объявлении класса, часто идёт и само определение кода его некоторых
методов.
При инкрементальной компиляции, компилятор каждый раз не генерирует
уже компилированые ранее классы с конкретно подставленными типами в
их шаблоны. А перекомпилирует только пользовательские изменения в коде.
Представляешь себе, сколько работы будет требоваться, скажем для
компиляции vector<string>, если ты просто в своём приложении
меняешь вызовы к объектам этого типа?
Скомпилированный по шаблону класс (напр. тот-же vector<string>) в инкрементальных
компиляторах хранится отдельно. В Sun'овских компайлерах помнится
для этого в текущем каталоге создавалось нечто типа .SUNWCache.
Интересно как это в gcc делается?
Ссылок в Инете я на эти мысли не нашёл, хотя тебя отошлю на
домашнюю страницу маэстро: