RedHat Linux 7.2

>A RedHat Linux 7.2 с человеческим лицом?
>А cp1251 тама есть? Очень хочется мигрировать свои исходники и
>документы между домом и работой без лишних телодвижений.

В RH имхо вряд ли. в седьмом меня просто убила куча "русских" локалей разной степени кривизны вместо одной-двух но нормальных с понятным названием.
В юниоре или спринге - есть.похоже в красной шапке просто не в курсе о существовании 1/6 части суши.

Кстати в сизифе у меня локаль кои8.
при этом открываю в гнумерик или абиворд соответственно doc rtf или xls
от MSoffice 95 и... вижу русские буквы. редактирую, сохраняю, иду в виндозу, открываю вордом или екселем и... русские буквы на месте!
как так получается - не знаю, но это уже реальность...

2maxcom (*) (2001-10-23 15:04:30.0) Гиблое дело. Времени жаль. Попробуй хотя бы собрать LICQ с поддержкой SOCKS5. Хоть с dante, хоть с nec'овской. Очень показательно трапается, при чем в разных местах :)

> 1) Это не прога, я ядровый модуль. Ядро пока еще не готово к сборке через gcc 2.96/3.0, специально для этого > есть kgcc. Утверждение о неюзабельности gcc 2.96 не обосновано. Когда gcc пишет "Internal Compiler Error", то утверждение о его *глючности* я считаю обоснованным, вне зависимости от того, был ли это модуль ядра, или ему вообще бинарник подсунули вместо исходника. И потом, многие скомпиленые им проги начинают глючить, некоторые потом трудно отлаживать, т.к. даже если скомпилить с -О0, всё равно иногда он делает какую-то оптимизацию. С kgcc пока проблем не было. Примеры всего этого здесь приводить нет смысла (вряд ли кто-то будет разбираться в исходниках и логах от gdb), лучше просто поссмотреть bugzilla или errata. Даже ссылку напишу, если кому лень набрать руками:) http://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Red+Hat+Linux&ver...

> 2) Утверждение о нерабочести нового glibc тоже пока вы не смогли > продемонстрировать. Я продемонстрировал некоторые из них на bugzilla (просто для проверки), но, как я и ожидал, они либо зависли в статусе ASSIGNED, либо перешли в WONTFIX и DEFERRED. Проще откатиться к более старой версии, чем пытаться что-то изменить. На счёт нерабочести - это к glibc из RH7.0. В 7.1 уже легче, но всё равно откатиться пока пришлось. Опять же, нет смысла здесь приводить примеры глюков, на которые наткнулся именно я: багзилла открыта для всех и там можно найти гораздо более показательные примеры.

> 4) Это просто мода нынче такая ругать RedHat без особых оснований > на то. Приведите реальные примеры проблем, Я привёл самый показательный пример (ICE). До меня другие люди тоже приводили свои примеры. Но это я "ругал" gcc-2.96, а не РедХат:) BTW, почему Debian гораздо реже ругают?

> без общих слов Это ведь обсуждение, а без общих слов это делается в соответствующих конференциях. Ну не хочется мне сюда исходники постить...

> и эмоций. За это извиняюсь. Просто логика "у меня всё в порядке, по этому глюков нет" мне действительно немного не понятна.

>Даже ссылку напишу, если кому лень набрать руками:)
>http://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Red+Hat+Linux&ver...

Сэр, в том списке идет речь про рание версии < gcc-2.96-87,
все давно уже используют 2.96-98(99), так что не надо говорить
про глюки, которые давно профиксили, gcc-2.96 ничем собственно
сейчас не отличается от 2.95, качайте новую версию и собирайте
все, что ранее не собиралось.... Кстати, это относится и к glibc,
RH ни в чем не виноват, что русская локаль там кривая, все их
дополнительные патчи к локалям никакого отношения не имеют,
они выкладывают ту локаль, которая есть в glibc'е, ну а
по поводу "??????" в XMMS, пинайте разработчиков глибса или
берите локаль с сизифа, в прочем, как и сами патчи на эту тему...

а зачем выдирать отдельные патчи из сизифа, когда можно просто взять из него все что нужно - и нормальный glibc, и нормальный 2.96 и 2.95 и все остальное собранное под пентиум, а не i386. Отдельные пакеты тут же пересобрать под свой проц и все остальное.
Просто непонятно, откуда у нас берутся фанаты RH? не дебиан, не Сусе и бсд на худой конец - просто на пустом месте образуется толпа желающих обкатать уже не очень новое но не интернационализированнное собрание глюков, кои уже во второй раз грозятся исправить и заменить свежими... :)))

Цитата из Линуса специально для защитников gcc-2.96:

In article <Pine.SUN.3.96.1001214042948.15033A-100000@eskimo.com>,
Clayton Weaver <cgweav@eskimo.com> wrote:
>
>There has a been a thread on the teTeX mailing list the last few days
>about a (RedHat, but probably more general than just their rpms)
>gcc-2.9.6 w/glibc-2.2.x bug. At -O2, it can miscompile

Quite frankly, anybody who uses RedHat 7.0 and their broken compiler for
_anything_ is going to have trouble.

I don't know why RH decided to do their idiotic gcc-2.96 release (it
certainly wasn't approved by any technical gcc people - the gcc people
were upset about it too), and I find it even more surprising that they
apparently KNEW that the compiler they were using was completely broken.
They included another (non-broken) compiler, and called it "kgcc".

"kgcc" stands for "kernel gcc", apparently because (a) they realised
that a miscompiled kernel is even worse than miscompiling some random
user applications and (b) gcc-2.96 is so broken that it requires special
libraries for C++ vtable chunks handling that is different, so the
_working_ gcc can only be used with programs that do not need such
library support. Namely the kernel.

In case it wasn't obvious yet, I consider RedHat-7.0 to be basically
unusable as a development platform, and I hope RH downgrades their
compiler to something that works better RSN. It apparently has problems
compiling stuff like the CVS snapshots of X etc too (and obviously,
anything you compile under gcc-2.96 is not likely to work anywhere else
except with the broken libraries).

Linus

Блин ребята вы че ?

Орут во всю глотку что все гсс2.96 кривой а сами дают
ссылку на использования его в 7.0 когда он еще не пропатчен
:((((((

Или в сторону Мандрак и всяких русских поделок -
да это те самые что РПМ базед !!! ( понятно откуда ноги растут )
Гляньте в ихи исходники все эти команды без патчей от Шапки
и жить то не смогли - постоянно все тащут от Шаповковцев.
У них Рав-Хиде про крону стоит :))))

А по поводу старого софта. Что значит старый - это про номера версий
что ли ? Да гляньте на их патчи .... и все сразу поймете.
У них более менее новизна и стабильность - в отличие от других !

Вот вам пример :
Выпустили это тормозное глюкало Нау. Шапки решили его в дистрибут
включить. И все перелопатили. ( кокс кстати лопатил )
Эти чайники из гнома увидели Шаповские патчи и сразу их к себе
и как следствие имеем Нау 105. Что есть аналог Шаповскому 102+
РХ патчи.

Так что пока Кокс и Цигнус и др работают на Шапку ее списывать
со счетов рано.

А по введению новых технологий ( не версиий прог ) а именно
новых технологий которые потом становяться для всех де факто
Шапке нет равных !!!!

Еще раз повторюсь
х.2 - оптимальный вариант более менее новизны
и стабильности.
х.0 - супер новые технологие и после патчей становяться
образцом для всяких тама Мандрак и все что из Шапок растет.

Какая разница, пропатченный или нет? Главное, что народ поимел неплохую головную
боль от 2.96 и еще долго в различных Readme и Install будет сидеть фраза
"don't use 2.96". Но мне все-таки интересно, какой выигрыш реально был или что
ожидали шляповцы от 2.96? 99% софта отлично собирается на 2.95.xx, а для оставшегося 1%
можно было положить gcc-3.01 куда-нибудь в contrib. Ну разве это не логично?
А то блин прямо как Интел с rambus - в теории все классно, а на практике дерьмо.

А чем это тебе Слакварь не нравится ??? В отличие от остальных - это самый чистый дистрибутив, минимум патчей хитропопых. И что ты считаешь за геморрой ? Работать надо, а не отбрехиваться. Если ты не знал, то в Слакваре есть пакаджы - аналог РПМок (;-)). Они в природе есть и компилять не обязательно их :-). Хотя , судя по публике, в этой теме собрались именно "компиляторы", которым должно быть известно как бороться с ситуациями, когда прога не собирается. Мне нравится Ред Хат,нравится Мандрейк, нравится Слакварь и еже с ними ! Для меня нет бьольшой разницы между ними ... и хватит воевать !!! :-).

Я рад, что появилась ещё одна версия Ред Хата.

Хватит звездеть.Шапка на куче чудиков обкатала гсс компилер, скорее всего поэтому так быстро 3 версия его вышла.Толпа юзверей и куча ошибок, только сиди и патчь.Не надо никаких тестов там выдумывать и все такое.Так что не надо ляля.10х шапка за твои эксперименты над людьми.(Slack,ASP user%)

Сижу на редхате с времен 4.2 И могу сказать одну вещь. Все эти годы, вселили уверенность, что если с любым из дистрибутов или пакетов случится кака нибудь жопа, ее ОБЯЗАТЕЛЬНО подправят. Это очень важно когда приходится администрить нцать компов с разными системами, пакетами в разных местах. Я просто читаю регулярно ERRATA и ставлю все секьюрити фиксы. делаю это раз в месяц, занимает это полчаса. И НИКОГДА НИКАКИХ проблем!

А все эти Altlinux, ASPLinux и прочая самодельная порнография вызывает только горькую усмешку. Ну что это за дистрибутив, когда в самой свежей версии Oracle не работает? Мне не нужны все эти пляски с бубном и колдовство. А помните Madrake 7.2 Russian Edition? На сайте iplabs полгода красовалась надпись о том что проект нафуй закрыт и теперь все будет по новому, по правильному. Кто мне даст гарантию, что через год ко всем этим Юниорам и прочим спрингам будут своевременно выпускаться все нужные апдейты?

В отличие от многих бакланов линуксоидов, я получаю от работы с линуксом не удовольствие, а деньги, поэтому я ценю свое время и удобство использования дистрибутива. Redhat дает мне уверенность в том, что вложенные усилия не пропадут даром, любая установленная система не останется без поддержки. Именно поэтому никаким супер пупер новинкам, включающм в себя самое, самое не переплюнуть редхат.

Да и последнее, поскольку время соит денег, то я предпочитаю стандартные вещи ставить из rpm. Так вот, на нормально установленном дистрибутиве RH, в потрохах которого не полазили алчные рученки линуксоида-мазохиста, все что нужно ставится на ура и без проблем. Может я что то не так делаю, где же глюки? Может я неправильный совсем?

P.S. 4.2 5.2 6.2 ... надеюсь что и 7.2 выполнит свою миссию и отработает положенный для них срок в 2 года, как это всегда бывало.

>А все эти Altlinux, ASPLinux и прочая самодельная порнография вызывает >только горькую усмешку. Ну что это за дистрибутив, когда в самой свежей >версии Oracle не работает?
Altlinux юниор->сизиф - Oracle работает

а что это за редхат и прочая самодельная порнография где в самой свежей версии dia русский текст не вводит? после установки иксы кракозябрами объясняются и локаль кривая? половину пакетов над обновлять самостоятельно? заливать пакеты по одному, смотреть buildrequires искать и заливать нужное и опять buildrequires и только потом ставить вместо _одной_ комманды апта? а патчи на русификацию (интернационализацию на самом деле) кто прикладывает?
Посмотрел бы ты в rpm -qi *.rpm - сколько там русских "самопальных порнографов" след свой оставило в виде патчей.

Редхат - хороший дистр. особенно для тех, кто в основном пользуется коммерческим закрытым софтом для линукса. Но для России, Украины, Белоруссии и других наших соседей - имхо Альтлинукс более оптимален.

Действительно, народ - хватить звездеть на редхат. Один из самых
правильных дистрибутов между прочим. У них свой :-) стиль, но это
ПРАВИЛЬНЫЙ дистрибут.
патчи свои проталкивают назад к авторам - раз
поддерживают свои изделия до упора - два
И САМОЕ ГЛАВНОЕ - предоставляют хорошую основу. Это часть их политики.
Именно это позволяет существовать всяким так Alt/Asp и даже
Мандрейку. Который при всем своем великолепии нацелен несколько
не на это. Редхат берется за неблагодарную работу,  в отличие
от всяких Мандрейков и прочих. А именно - продвигать самую консервативную
часть Gnu/* - компилятор. (продвигать не всмысле рекламировать :-))
PS
И кстати Mandrake,Alt,Asp, mplayer .... У кого еще есть максимально полная
поддержка кербероса в дистрибутиве кроме Шапки ? Мне интересно.

to kernel:
абсолютно согласен с каждым словом.
редхат дал основу для многих дистров и если есть куча RH-based дистров то наверное нет ни одного альтлинукс или асп -based :)

я только не пойму смысла противопоставления этих дистров. Я вот пользуюсь галеоном и не люблю мозиллу. И это не нонсенс. Ребята из российских комманд-разработчиков делают весьма неслабый вклад в продвижение линукса на наши просторы и не надо на них волну гнать.

Это очень хорошо, что RH выпустила новый релиз, но пользоваться им удобно ТАМ, а нам бы чего поудобней, посекурней, посвежее и чтоб с локализацией проблем поменьше и т.д.
А это - бывший RH-based Спринг,Юниор, Сизиф.

PS. я к альтлинуксу отношения не имею. просто пользовался разными дистрами и сейчас вот работаю на Сизифе. Это первый полноценный десктоп под линухом, который действительно заменил мне полностью виндОс и работает на ура.

Чё за Сизиф? Поделитесь? 1251 без проблем? все работает и в консоли тоже?

предыдущему анониму:
Здесь не место наверное для таких обсуждений.
это целое семейство из дистрибутивов для десктопа junior 1 cd, сервера castle 1 cd и универсального spring 4 cd. Плюс общий репозитарий пакетов Сизиф. Я рекомендую при наличии интернета купить юниор 1.1 и проапгрейдить его из сизифа. Это делается одной коммандой апта.

За информацией зайдите на www.altlinux.ru
там также можно почитать или подписаться на список рассылки mandrake-russian.
Узнаете много нового и полезного.

Avel, Спасибо за информацию, а что насчет ответа на вопрос?

По поводу gcc-2.95.3, который считают тут многие прямым....
-mcpu=athlon, попробуйте что-нибудь с этим ключиком
скомпилить, или что-нибудь связаное с fpu на том же атлоне....

то анонимус
насчет локали 1251?
есть там она, как и белорусская так и хохлятская кои8.
также есть казахская utf8. ;)

по поводу прямости ее реализации.
вообще говоря локаль там сама по себе прямая.
вопрос в большом количестве некорректно локализованных программ и оболочек.
Если ставить из спринга на сразу на локаль 1251 - кое где будут вылезать кракозябры и сообщения в кои8.
В сизифе уже все гораздо лучше. Есть люди которые только на этой локали и живут.
Я делаю по другому. Ставлю ОБЕ локали КОИ8 и 1251 и использую в основном кои а при необходимости запускаю прогу примерно так:
export locale=cp1251;my_proga и имею программу в окружении 1251.
так вообще проблем нет (с кдешными прогами фокус особый, но у меня нет кде и я его не помню).

Такие вещи лучше все таки выяснять в форуме данного дистра.

По поводу gcc-2.95.3, который считают тут многие прямым....

это действительно хороший компилятор. его слабое место и причина "прямости" - слабая оптимизация и незнание особенностей архитектуры свежих процов. Его стихия 386-пентиум и не надо требовать от него большего. Это компат-компилер. Когда ваша прога рюхается под 2.96 или 3.0х остается последний довод программера gcc2.95 (или править исходники:)

-mcpu=athlon, попробуйте что-нибудь с этим ключиком
скомпилить, или что-нибудь связаное с fpu на том же атлоне....

он не знает про атлон. не надо загонять компилер в ненормальные условия. используйте 2.96 последних билдов для ядра и старых прог и 3.0 для тех прог которые этот 3.х сможет собрать :).
прог под гсс3 немного и в сизифе до сих пор этого компилера нет. я его собрал для себя, погонял и решил, что АЕН и компания правильно его пока не включили. Рано. А вот гонщики за дешевой популярностью (не будем показывать пальцем) включили и дуют теперь щеки.

> -mcpu=athlon, попробуйте что-нибудь с этим ключиком

А кто-нибудь пробовал замерить скорость исполнения такого кода?
Я сам не пробовал, но в конференциях проскакивали данные о том, что
gcc-3.0 при прочих равных условиях компилит на 5-10% более медленный код.
А если он более медленный, то спрашивается, зачем козе баян? Ну допустим,
ключик -mcpu=athlon сравняет код по скорости с тем, что мы имеем на gcc-2.95
с ключом -mcpu=pentiumpro. Ну и что? При одинаковой скорости получили
непереносимый на другие cpu бинарник. В чем радость-то?

> собрал  для  себя,  погонял  и решил, что АЕН и компания правильно его
> пока  не  включили.  Рано.  А вот гонщики за дешевой популярностью (не
> будем показывать пальцем) включили и дуют теперь щеки.
Они его включили, но он не основной. Это лучше чем не включать его
совсем.

> Они его включили, но он не основной
Это я про RH72 говорил естественно.

>А кто-нибудь пробовал замерить скорость исполнения такого кода?
>Я сам не пробовал, но в конференциях проскакивали данные о том,
>что gcc-3.0 при прочих равных условиях компилит на 5-10% более
>медленный код.

Для атлона лучше всего использовать gcc-2.96, он с этим ключем
делает код, который быстрее того кода, который получается от
gcc-2.95.3, всетаки оптимизация для атлона в gcc-2.96 имеется,
в отличии от...
Но дело немного не в этом, многие ./configure определяют тип
проца, и пытаются выставить -mcpu=athlon, от которого у
gcc-2.95.3 едет крыша. Это дело конечно фиксится заглушкой
для gcc или патчами от agcc, либо ковырянием ./configure, но только
вот fpu атлона будет работает криво или вовсе не работать, даже
патчи от agcc в этом не помогут, и остается только одно -
использовать для К7 gcc-2.96 как не крути, и код при этом быстрее
и с fpu все нормально...

>Но дело немного не в этом, многие ./configure определяют тип
>проца, и пытаются выставить -mcpu=athlon, от которого у
>gcc-2.95.3 едет крыша.
просто горе от ума каое-то
rpm -ba trststs.spec --target=i586 --cc=kgcc
делает имено на атлоне именно на 2.95 и именно бинарник на i586 %)

документацию надо же читать. а не патчить то что и так прекрасно работает.

имхо configure --target=i586 делает тоже самое.
возможно configure --march=i586 --cc=kgcc
будет точнее. просто я уже давно собираю из тарболов рпм а его уже собираю и точно не помню, как оно делается.

> Они его включили, но он не основной
Это я про RH72 говорил естественно.

это очень, очень хорошо!
1)теперь в редхате три компилятора gcc? gcc (2.96) kgcc(2.95) 3gcc(3.0.10) прогресс, мать вашу. скоро под каждую прогу будет свой компилер! или они выбросили 2.96? или 2.95? Доиграются, имхо...
2)пусть подопытными свинками побудут все пользователи шапки, а мы уж как нибудь тогда перейдем, когда это реально будет иметь смысл.

>просто горе от ума каое-то
>rpm -ba trststs.spec --target=i586 --cc=kgcc
>делает имено на атлоне именно на 2.95 и именно бинарник на i586
>%)

Я плохо выразился? Ведь сказал же _определяет_, при этом
ключи и set'ы ей по барабану, так как программа собирается
компилиться с поддержкой 3DNow, и ключ при этом configure
берет не с окружения или опций, а из маленькой такой встроенной
програмки, которая лезет обычно в /proc/cpuinfo и берет
информацию о процессоре там, без напильника тут не обойтись...

А я вот юзаю pgcc, и не имею траблов ни с собиранием софта ни с производительностью. Пока gcc-3.0 проигрывает pgcc

to McMCC:
>Я плохо выразился?
куда уж хуже.
Определять конфигуре может все что угодно. это его право. а вот собирать программу _только_ для той машины, на которой эта прога и собирается - это просто бред и фуфел.

править такую прогу придется по любому. Я вот каждый пакет собираю и для своего атлона и для всех совместимых с пентиумом. Могу еще для 386 собрать. и наверное пару пакетов скоро соберу чтоб на дешевенький ноут поставить. Это не беда компилятора и вообще окружения - это беда конкретного configure. Я, правда, таких прог пока не видал, за исключением библиотек с _требованием_ атлона, бо написаны они спец. для него.

>А я вот юзаю pgcc
это от интеля ?
некорректно сравнивать отдельный, заточенный компилер под пентиум и основу всех основ - gcc

одно другого не заменяет и не взаимоисключает. нравится pgcc - пользуйся им, но gcc все равно остается незаменимой основой всего линукса и не только...

Это я про RH72 говорил естественно.
это очень, очень хорошо!
1)теперь в редхате три компилятора gcc? gcc (2.96) kgcc(2.95)
3gcc(3.0.10) прогресс, мать вашу. скоро под каждую прогу будет свой
компилер! или они выбросили 2.96? или 2.95? Доиграются, имхо...
На ./ пишут что 4 (откуда 4ый взялся - мне неизвестно). 3.0 ставят
только разработчики, которым нужна поддержка С++ в полном соответствии
со стандартом (или которые думают о будущем). Юзерам и админам 3.0
ставить не нужно. Считать кол-во компилеров - глупо (пока они бесплатые:).

>Считать кол-во компилеров - глупо (пока они бесплатые:).
весьма глупо индиферентно относиться ко все более разрастающемуся количеству параллельно существующих и одновременно необходимых версий одних и тех же компилеров и их библиотек.
Уже имеем спецприблуду update-alternativites специально для настройки корректной работы этого зоопарка.
Надо отлаживать gcc 3.х, но надо ли включать его в _универсальный_ дистрибутив, предназначенный для всех и в основном для чайников и админов?
Имхо это и есть профанация хорошего дела и дешевая популярность (и слава глюкмейкеров)
2.96 включили в шапку рано, теперь тычат 3 версию, как будто ничему не научились даже на собственном опыте...

Бля, "пакеты сам под себя компиляю, *gcc* не такой "
Вам, наверное, делать нехрена.
А процессор под свой ток в розетке паяльником - слабо?
Или авто под бензин в соседней бензоколонке.
Тоже, ведь, производительней будет.

Где взять pgcc-*.*.*-src.rpm толковый ?

Неа. В 8.0 они перейдут на _следующую_ бету - типа 3.12 rh. Нет им веры.

   весьма  глупо  индиферентно  относиться  ко  все более разрастающемуся
   количеству  параллельно существующих и одновременно необходимых версий
   одних и тех же компилеров и их библиотек.
   Уже  имеем спецприблуду update-alternativites специально для настройки
   корректной работы этого зоопарка.
gcc-3.0 ставить *НЕ* обязательно.
А 4-ым по счету компилятором в RH наверно яв-ся gcc-2.95 (итого 2.8.1 (kgcc),
2.95.x,2.96,3.x).
   Уже  имеем спецприблуду update-alternativites специально для настройки
   корректной работы этого зоопарка.
Оно нужно не только для gcc, но и для многих других вещей.
   Надо  отлаживать  gcc  3.х,  но надо ли включать его в _универсальный_
   дистрибутив,  предназначенный  для  всех  и  в основном для чайников и
   админов?
gcc-3.x включен в основном не для его отладки, а для затачивания
софта программерами под него. А чайники и админы пусть его не ставят.
   2.96 включили в шапку рано, теперь тычат 3 версию, как будто ничему не
   научились даже на собственном опыте...
Насчет 2.96 полностью согласен. 3.x они не тычат - они любезно
предоставляют его разработчикам для тестирования со своими програмами.
Он не обязателен.

>"пакеты сам под себя компиляю, *gcc* не такой "
>Вам, наверное, делать нехрена.

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

>Или авто под бензин в соседней бензоколонке.

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

не тупи.

to hvv:
я, вобщем, ничего против RH не имею.
просто мне кажется, что вещи типа gcc 2.8 и gcc 3.0.1 должны бы по идее лежать на ftp редхата и идти девелоперским отдельным диском.
четыре версии одного компилятора в одной поставке - из которых реально используется только 2.96 и иногда 2.95, это неправильно.
Количество ошибок, совершенных не очень опытными пользователями будет тяжким грузом давить на реноме шапки.
плохо это, для всех плохо, для линукса в целом, а не только для шапки.

> Но дело немного не в этом, многие ./configure определяют тип
> проца, и пытаются выставить -mcpu=athlon, от которого у
> gcc-2.95.3 едет крыша.

Ну а тогда пример в студию?!
Какой такой ./configure без спросу делает -mcpu=athlon?
Я знаю, например, что mplayer очень тщательно пытается определить проц и
оптимизировать код под него. Дык он же самый первый на 2.96 и ругается,
а под 2.95.х собирается на ура ;)
Так что уточни, плиз, свое утверждение примером(ами).

>Ну а тогда пример в студию?!
>Какой такой ./configure без спросу делает -mcpu=athlon?

XINE пойдет?
rpm -bb --target i686 guenter.spec
....
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../.. -I../../src -I../../src
-I../../src/xine-engine -I../../src/xine-engine -I../../src/xine-utils
-I../../src/xine-utils -O3 -pipe -fomit-frame-pointer -malign-functions=4
-malign-loops=4 -malign-jumps=4 -malign-functions=4 -mwide-multiply
-mpreferred-stack-boundary=2 -fexpensive-optimizations
-fschedule-insns2 -fno-strict-aliasing -ffast-math -funroll-loops
-funroll-all-loops -finline-functions -mcpu=athlon -Wall -D_REENTRANT
-D_FILE_OFFSET_BITS=64 -DXINE_COMPILE -I/usr/include/kde/artsc -c
video_decoder.c -fPIC -DPIC -o video_decoder.lo

Хорошо видно -mcpu=athlon?
Может мне еще написать как это делает configure? Там
довольно все просто....

>Я знаю, например, что mplayer очень тщательно пытается
>определить проц и оптимизировать код под него. Дык он же самый
>первый на 2.96 и ругается, а под 2.95.х собирается на ура ;)

Там это правится как нефиг делать, и помойму уже есть ключик
к configure, он собирается под 2.96 и прекрасно работает, так что
не надо ляля....

> Avel
> не тупи.

А Oracle тоже сам компилишь? А то, по-твоему, его нельзя юзать он же для 386.

Нет, друг, это когда делать нехрена ламерам они этим страдают,
а серьезные дяди трудятся.

> XINE пойдет?
> rpm -bb --target i686 guenter.spec

Ах, это глюкало... А говорил многие. Это не страшно.

>А Oracle тоже сам компилишь? А то, по-твоему, его нельзя юзать он же >для 386.

коммерческий, закрытый продукт я буду компилировать?
я даже не знаю,есть ли там открытые исходники.
за что тогда деньги платить? (слышал, что последний беплатно раздают, но это не имеет абсолютно никакого значения - коммерческий продукт подразумевает другое отношение.)
AVP я тоже не перекомпилирую.
а вот все пактеики одним скриптом на --rebuild посылаю и не плачу потом, что быстродействие маленькое. У меня загрузка гнома проходит за 5-7 секунд. и дальше тоже без тормозов и мозилла и наутилус.

>Нет, друг, это когда делать нехрена ламерам они этим страдают,
>а серьезные дяди трудятся.
тупой ты. я завязываю...

У меня xine из сизифа собирается именно с той опцией --target
какую дам. или автодетект, если промолчу.
так что его даже править не надо - только бери в правильном месте.

>Ах, это глюкало... А говорил многие. Это не страшно.

2anonymous: Ты просил пример, я тебе его дал, покрайней мере
тот, с которым я недавно столкнулся, так что не надо
оправдоваться. Глюкало оно или нет, мне это побоку, работает
xine по моим понятиям не хуже остальных плееров и даже лучше,
покрайней мере нет рассинхронизации видео со звуком, как
к примеру в mplayer'е, можно не только смотреть, но и слушать
музыку, впрочем DVD&VCD проигрование в нем тоже гораздо лучше
реализовано чем в mplayer'е, дружит с arts и esd напрямую...

P.S. Все раннее приведенные доводы о кривизне gcc-2.96,
не убедительны! 2.96 не стоит на месте, сегодня он довольно
стабилен и не уступает gcc 2.95.3, проверено мной не однократно
и не на одной программе, так что свои мнения оставляйте при себе,
не нравится - не ешь, ни кто вас не заставляет использовать
2.96, всегда его можно заменить на 2.95.3, взяв его, например,
с того же rawhide для os390 в директории SRPMS и собрать...
P.P.S Я что то не вижу особых наездов на gcc 3.0.x, в котором
много чего взято от 2.96...

> Ты просил пример, я тебе его дал, покрайней мере
> тот, с которым я недавно столкнулся, так что не надо
> оправдоваться.

Я вообще-то хотел примерЫ, поскольку самым спорным в твоем утверждении
была фраза про "_многие_ ./configure". А оказался только один. Что и требовалось
доказать.

Какие кодеки аудио/видео ты используешь в mplayer'e? Я прокрутил на нем
сотни фильмов и никогда не видел рассогласования. Только по желанию плюсиком ;)
Что не так у тебя в местных настройках.

gcc-2.96 не есть официальный релиз. Этим все сказано. Из известных прог он
не компилит XFS (то есть даже самый последний gcc-2.96 имеет проблемы).
Это тоже немаловажно.

Я непонимаю что вы обсуждаете выход RH 7.2 или выход 7.0 после 6.2 Вы сами его видели , ставили. Я его поставил и очень им доволен хотябы тем что убраны проблеммы с русским языком и при инсталяции и при работе в Иксах. Можно сказать что ребяты работают и работают неплохо.Главное что человек каторый впервые купит линух увидит вполне нормальный дистриб имеющий нормальный набор покетов с нормальным русским языком.

>Я вообще-то хотел примерЫ, поскольку самым спорным в твоем
>утверждении была фраза про "_многие_ ./configure". А оказался
>только один. Что и требовалось доказать.

Я лишь привел последний пример, с которым я имел дело, ранее
мне тоже встречались такие configure, так что понятие "_многие_
./configure" в полне оправдано, в будущем это будет уже во
всех программах, и это правильно, мне не интересно выставлять
тип процессора, когда по идее это должна делать configure и
подключать соответствующие оптимизации и поддержки 3DNow,
MMX, SSE. Учтите, gcc-2.95.3 уже изжил свое, в особенности на
новых процессорах, да он и не будет вечным, т.к. с C++ у него
совсем худо, как в прочем и с JAVA компиляцией...

>Какие кодеки аудио/видео ты используешь в mplayer'e? Я прокрутил
>на нем сотни фильмов и никогда не видел рассогласования. Только
>по желанию плюсиком ;) Что не так у тебя в местных настройках.

Вот про "прокрутил на нем сотни фильмов и никогда не видел
рассогласования", только мне не говорите, я его тоже использую,
но xine мне показался более грамотным, кодеки в xine и mplayer'e
одни и те же, но в xine их больше, например для mp3 можно
подключить mad по мимо mpg123, мне гораздо нравиться тот
факт, что я могу использовать вывод звука на esd или arts не
используя какой либо дополнительной либы, что бы это сделать
в mplayer'е, мне приходится задействовать SDL, а если его
кто то не хочет ставить по каким либо соображениям? Прикажете
использовать вывод через oss/alsa? Учтите, /dev/dsp не резиновый,
только коммерческий oss может позволить сделать микширование
для нескольких источников и то не на всех картах...


>gcc-2.96 не есть официальный релиз. Этим все сказано. Из
>известных прог он не компилит XFS (то есть даже самый последний
>gcc-2.96 имеет проблемы). Это тоже немаловажно.

Это все отговорки и не желание многих писать код с условием
этого компилятора... А как по вашему, gcc-3.0.x тоже не
официальный или как? Он тоже не будет компилить вашу любимую
XFS, раз этого не делает 2.96, для таких вот случаев в RH7.x
предусмотрен compat-gcc(kgcc)(egcs-1.1.2)(gcc-2.91.66) который
тут почему-то по ошибке называют gcc2.95?!....

RedHat сасёт, 6.2 последний лучший билд.!!!