Странный выбор. А почему не gcc 2.95.2? А почему вобще не писать код так чтоб он больше соотносился со стандартом? Вот скоро gcc 3.0.x выйдет, а Linux опять будет как белая ворона и даже без CVS?

и вообще пора на c++ писать

кернел? на плюсах? не смешите мои тапочки..

А правда, какого ... сей зверь не рекомендуется с gcc собирать? Кстати, пробовал я как-то через gcc собрать ядро с редхатовскими патчами, так все висло просто изумительно. Без патчей же все работало. Вроде бы... Правда, я этот комп пользовал только как рабочую станцию...

Хм, а в FreeBSD начиная с версии 3.4 (насколько я помню) системным компилятором является gcc-2.95.2 . И все компилится вполне нормально, в том числе и ядро. Интересно, что линуксу мешает. Если у кого-то есть правдоподобные сведения по этому поводу, плиз в студию.

Потому, что при разработки ядра Linux не ставилось цели сделать ядро, переносимое между разными компиляторами C. По этому ядро завязано на некоторые специфичные для gcc вещи, которые иногда меняются при смене версии gcc. Более подробно это можно прочитать в "Linux Kernel Code Commentary". Кстати, проблем со сборкой ядра посредством gcc 2.95.x нет, но поскольку основные разработчики используют egcs 1.1.2, гарантии что все "ок" нет. С последними снапшотами gcc (2.96/2.97) известны проблемы, собирать ядро ими ненадо.

У меня и редхатовским 7 компилятором ядро собралось и работало недолго пока не стал ipsec прикручивать и компилять с еррорами дикими и не обламался и не вспомнил что надо другой компилер юзать.

Predlagau otstrelivat' vseh developerov, which use egcs. Vsem namnogo legche stanet.

Это как? Вроде в относительно свежих дистрибутивах именно egcs является дефолтным компилятором

> Predlagau otstrelivat' vseh developerov, which use egcs. Vsem namnogo legche stanet.

лучше отстрелить всех анонимусов, которые несут чушь

кто нибудь мне объяснит толково , почему использование ц++ для написания ядра плохо (кроме того, что понадобится разработка ООП архитектуры для ядра) ?
С удовольствием подискутирую.

писать сюда: gerda@sendmail.ru

2Havoc: Ne... Eto v syryh distro egcs. Ja SuSE usau.

(2gerda)Re: Прощай gcc 2.7.x

Тебе вывалить всю переписку из l-k на эту тему? :)

Нет. Мне просто хотелось бы услышать доходчивое объяснение, которое меня бы удавлетварило. Вавсех смыцлах.

А вот на выбор два доходчивых объяснения: 1. Когда-то, в древние времена, ядро как раз и писалось на c++. Но было это так давно, что приличного компилера c++ - не было, а c - был. Посмотрели-посмотрели разработчики - да и плюнули, и пишут с тех пор на c. Сейчас-то g++ 2.95.2 крут - да только поздно. 2. Косность. Как сказал Страуструп, не по поводу конкретно линуксового ядра, а так, вообще, почему писатели open source не особо любят c++: "Старую собаку не научишь новым фокусам".

2gerda:
На то причин много:
1. C++ в полном виде не необходим. Было бы, конечно, приятно написать:

class 3c905_nc : FastEthernet_nc
{
rx (net_device dev&) ;
start_xmit (net_frame_buff skb&,
net_device dev&) ;
....

}

а потом

int 3c905_nc::rx (net_device dev&)
{
Hardware::inw (3c905_nc::get_hardware_status (dev.base_addr),
3c905_nc::get_Rx_status (dev.base_addr)) ;

....
}

однако наследование осуществимо с помощью функции register_netdev
и unregister_netdev (в данном случае), и ощутимой выгоды не видно.

2. C++ требует "environment"
Т.е. поддержка таких перлов как dynamic_cast и throw/catch.

3. gcc генерирует хороший и компактный C код. (I mean stable and released gcc, dont sod me with 2.96 vs 2.95 vs 3.0 issues)

Нда, вставлю свои пять копеек. IMHO основная причина неиспользования C++ -- отсутствие людей, умеющих его грамотно использовать (надеюсь никто не будет возражать, что для написания _kernel_ надо очень хорошо знать OOD/C++). За последние 10 лет я видел _единицы_ людей, знающих хотя бы основы OOD (внимание! D stands for design!). А без этого на C++ писать не получается, вернее, уж лучше на C писать, а то получается не С++, а Visual C++. :( Да и использование C создает психологический барьер для ламеров (как и отсутствие kernel debugger). Что-то я не припомню "C guide for complete idiot", а вот "C++" в сочетании с "dummy", "idiot" и "24 hours" -- на каждом углу. А что ecgs, а не что-то новее -- это даже хорошо. Потому как gcc 2.9x мягко говоря сыроват для всего, кроме x86. Ведь у нас же линукс не только под x86.

Мне кажется ядро на С++ будет медленее чем на С. sam

Ну и нормально. Просто старый уже совсем устарел... Кстати, о птичках, в Mandrake 7.0 ядро собрано gcc 2.95.2.... И ведь не глючит, зараза такая!

В Mein Dreck не глючит??? Расскажи это моему компу. Особенно мне понравилось, что если собирать проект с shared libs, то имею seg fault в произвольном месте, в если все static linked -- работает "на ура". Может, конечно, ему AMD K6 не нравится, но мне-то от этого не легче. Dreck он и есть dreck. Dronov, рассматривая мужика в красной шапке.

Ne smeshite. 2.95.2 po opredeleniu perenesen luchshe na bolshee chislo platform i soderzhit menshe glukov, tak kak eto RELEASE, a ne SNAPSHOT.

> Ne smeshite. 2.95.2 po opredeleniu perenesen luchshe na bolshee chislo platform i soderzhit menshe glukov, tak kak eto
> RELEASE, a ne SNAPSHOT.

egcs-1.1.2 это качественный релиз, а не снапшот. Чего например нельзя сказать
о некоторых релизах gcc, из серии 2.8.x

По-моему, в ядре многие вещи ( VFS, например ) и так сделаны с помощью OOD. И язык Ц тут OOD совершенно не мешает.

То что VFS сделан с применением указателей на функции, еще не есть OOD. Как где-то процитировали Вирта, виртуальная функция - просто переменная "функционального типа". (Это утрирование конечно.) Согласен с 5 копейками Dronovа. Хотя надо брать не 10 лет, а 5-6: Липпман, Коплейн и Банда Четырех - это где-то 91,92,94 годы или около этого.

2maxcom: http://gcc.gnu.org/releases.html Читай. Ты egcs 1.0.2 юзал? Я юзал. Кошмар. Ниначём, кроме i386 linux, нормально не работал... Так вот: gcc 2.8.1 - то же самое, но с поддержкой большего числа платформ и т.п. И жаль, сейчас трудно найти пресс-релиз egcs - egcs ВСЕГДА шёл как отладочный проект по добавлению фич в gcc, и по началу он действительно был предпочтительнее чем старый gcc (у которого c++ считай и не было). Но в нём, например, нет запрета на не-ANSI извращения, в результате ПОВСЕМЕСТНО народ легко использовал такие фишки, как неявное преобразование типов... Николас Вирт застрелился бы. И RELEASE всегда предпочтительнее.

Для тех, кто думает, что 2.95.2 "лучше" egcs на _РАЗНЫХ_ платформах. Найдите Digital Alpha (пардон, compaq) и скомпилите свой любимый бенчмарк родным dec'овским cc, egcs-1.1.2 и gcc 2.95.2. Вы будете неприятно удивлены насколько худший (медленный) код дает 2.95 и приятно удивлены близостью результатов dec cc и egcs. Причем разница будет не в процентах а в "разах". Так что, еще раз, для всего, кроме i386 (в это "кроме" входит и i[56]86 -- пример проблем: mandrake, btw XFree уже отменила свою рекомендацию "ни за что не собирайте XFree86 с i586 оптимизацией"?) сейчас есть только один компайлер -- egcs. P.S. Мы, вообще-то, в этом треде разговариваем про kernel, для которого соответствие ANSI С++ нафиг не нужно (там же plain C).

Ну, на Альфе даже egcs близко к родному DEC C подойти не может. А вот на ultrasparc 2.95.2 весьма сильно обошел старые egcs (правда, с родным соляркиным я не сравнивал...).

segfault в произвольном месте с шареными либами - верный признак того, что про PIC забыли.

vsl, я не настолько ламер. PIC в "Hello world"? Вернее, похоже да, похоже в mandrakesoft кто-то забыл PIC при сборке glibc. Точнее, printf("Hello world\n"); работает, а вот уже { int a; printf("Hello world!\n"); a = 100; printf("Hello again!\n"); } начинает подглюкивать. Причем если собирать с '-g -O2 -mpentium' то уже падает через два раза (с просто -g или -O2 валится нафиг "внутре" glibc). Было сильное подозрение, что если собирать с какими-то "магическими" ключами, то работать будет, но мне проще было поставить шапку (проблемы сразу исчезли). А про Alpha -- ну, приукрасил. Но и то не сильно. По сравнению с разрывом egcs <-> 2.95, разрыв egcs <-> dec cc просто незаметен.

Работал только на Sparc и HP, но специально знакомого на уши поставлю, чтобы gcc проверить.

Хм... А если дебаггером пройтись - где выпадает?

X его знает. Не помню. Я не для того кровные $5 отдавал. :) У меня уже тогда были подозрения в его (mein dreck) политической неблагонадежности (но я до того момента как-то ничего на той машине не копилил, у меня весь /usr/local от suse остался), а как только оно упало, а bt "завел" меня куда-то в libc (я уже не помню точно), подозрения переросли в уверенность и я с криком "ага, попался!" достал с полки CD с RH. Это на самом деле фигня. Там были какие-то странные глюки с кернелом (оно _просто_ висло в произвольные моменты). Железо, конечно, кривое до безобразия, но ни SuSE, ни Red Hat, ни FreeBSD, ни даже Win98 (когда оно еще там было) ничего "этакого" себе не позволяли. Причем под SuSE у меня uptime доходил до недель (это ноутбук, вообще-то).

Так а чем SuSE помешал?

Re: Why not suse? перечисляю только запомнившееся: отчаянная кривизна rpm: 99% src пакетов не имеют понятия о RPM_BUILD_ROOT. Из "мелких", но мерзопакостных: зависимостью xmms->gnome, а не xmms-gnome отдельным пакетом как у RH. и, что было критично, оно не могло читать свои же core files. пересборка gdb, kernel, etc не помогла. Mein Dreck, RH and FreeBSD -- проблем с чтением _core_ нет.