# Плач разработчиков

## GCC 2.96

Предпосылки:

GCC 2.95 серий — это официальный GNU релиз и версия 2.95.3 — максимально свободная от ошибок в этой серии. Мы никогда не замечали проблем компиляции, которые можно было бы отнести на счёт gcc-2.95.3. Начиная с RedHat Linux 7.0, Red Hat включили сильно пропатченную CVS версию GCC и назвали её 2.96. RedHat включили эту версию в дистрибутив, поскольку в то время GCC 3.0 не был завершён, а им требовался компилятор, который бы хорошо работал на всех поддерживаемых платформах, включая IA64 и s390. Дистрибьютор Linux Mandrake, последовал примеру Red Hat и начал поставки GCC 2.96 с Linux-Mandrake серии 8.0.

Заявления:

Команда GCC отрицает все связи с GCC 2.96 и даже выпустила официальный ответ на GCC 2.96. У многих разработчики со всему мира возникали проблемы с GCC 2.96, и они рекомендовали другие компиляторы. Примеры — это MySQL и avifile. Прочие интересные ссылки — это Linux kernel news flash о ядре 2.4.17 и Voy Forum. MPlayer также претерпевал различные проблемы, которые разрешались переходом на другую версию GCC. Некоторые проекты начали осуществлять обходы для некоторых проблем 2.96, но мы отказались исправлять ошибки других людей, в том числе поскольку некоторые такие обходы привели бы к потере производительности.

GCC 2.96 не допускает символ `|` (pipe[канал]) в ассемблерных комментариях, поскольку он поддерживает Intel'евский и AT&T синтаксисы, а буква `|` — символ в Intel'евском варианте. Проблема в том, что он молча игнорирует весь ассемблерный блок. Теперь, это предположительно исправлено, GCC печатает предупреждение, а не пропускает блок.

Текущее состояние:

Red Hat заявляет, что GCC 2.96-85 и далее исправлены. Ситуация действительно улучшилась, хотя мы всё ещё видим в рассылках сообщения о проблемах, которые исчезают после перехода на другой компилятор. В любом случае, это больше не важно. Предположительно готовый GCC 3.x должным образом разрешит эти вопросы. Если Вы хотите скомпилировать, используя версию 2.96, укажите опцию `--disable-gcc-checking` в `configure`. Помните, что Вам решать, и не сообщайте об ошибках в этом случае. Если Вы попробуете, Вы будете изгнаны из наших рассылок, поскольку у нас уже было достаточно 'сражений' из-за GCC 2.96. Давайте оставим эту тему в покое.

Если у Вас проблемы с GCC 2.96, Вы можете скачать 2.96-85 пакеты на ftp сервереRedHat, или просто перейти на 3.0.4 пакеты, предлагаемые начиная с версии 7.2. Вы также можете использовать gcc-3.2.3-11 пакеты (неофициальные, но работают нормально) и поставить их совместно с gcc-2.96, который у Вас стоит. MPlayer их обнаружит, и будет использовать 3.2 вместо 2.96. Если Вы не хотите или не можете использовать пакеты, вот как Вы можете скомпилировать GCC 3 из исходного кода:

- Пойдите на страницу GCC зеркал и скачайте `gcc-core-XXX.tar.gz`, где XXX — это номер версии. Этот файл включает полноценный компилятор C, которого достаточно для MPlayer'а. Если Вы также хотите C++, Java или какие-нибудь другие дополнительные возможности GCC, Вам, возможно, больше подойдёт `gcc-XXX.tar.gz`.

- Распакуйте архив:

      tar -xvzf gcc-core-XXX.tar.gz

- В отличие от других программ GCC собирается не в каталоге с исходным кодом, а в отдельном каталоге. Поэтому вам нужно создать этот каталог, выполнив

      mkdir gcc-build

- Теперь Вы можете приступить к конфигурированию gcc в каталоге для сборки, но Вам нужно конфигурировать из каталога с исходным кодом:

      cd gcc-build
      ../gcc-3.XXX/configure

- Скомпилируйте GCC, выполнив эту команду в каталоге для сборки:

      make bootstrap

- Теперь Вы можете установить GCC (как root), выполнив

      make install

## Распространение в двоичном(скомпилированном) виде

Прежде MPlayer содержал исходный код из проекта OpenDivX, который не разрешал распространение в скомпилированном виде. Этот код был изъят, начиная с версии 0.90-pre1, а остававшийся файл `divx_vbr.c` , основывающийся на исходном коде OpenDivX, помещён под GPL его авторами, начиная с версии 0.90pre9. Теперь Вы можете создавать скомпилированные пакеты, если Вам захочется.

Другим препятствием к распространению в двоичном виде была оптимизация времени компиляции под конкретную архитектуру процессора. Теперь MPlayer поддерживает определение CPU во время выполнения (укажите `configure` опцию `--enable-runtime-cpudetection`). Это по умолчанию выключено, поскольку это вызывает небольшую потерю в скорости, но зато теперь возможно создавать бинарии, которые будут работать на разных CPU из семейства Intel-совместимых.

## nVidia

Нам не нравится то, что nVidia предоставляет только двоичные драйверы (для использования с XFree86), которые часто бывают глючными. У нас было много сообщений в mplayer-users о проблемах, связанных с этими драйверами с закрытым исходным кодом, их плохим качеством, нестабильностью и плохой поддержкой пользователей и специалистов. Многие из этих проблем продолжают появляться снова и снова. Мы всегда связывались после этого с nVidia, и они говорили, что эти ошибки не существуют, что нестабильность вызывается плохими AGP чипами, и что они не получали сообщений об ошибках в драйверах (таких, как пурпурная линия). Поэтому, если у Вас проблема с nVidia картой, мы можем только посоветовать обновить nVidia драйвер, и/или купить новую материнскую плату, или попросить nVidia предоставить драйвер с открытым исходным кодом. В любом случае, если Вы используете двоичный nVidia драйвер и столкнулись с проблемой, связанной с драйвером, знайте, что Вы почти не получите помощи с нашей стороны, поскольку в этом случае у нас почти нет возможности Вам помочь.

## Джо Барр[Joe Barr]

Джо Барр получил дурную репутацию, после написания менее, чем благосклонного обзора MPlayer'а, названного MPlayer: The project from hell[MPlayer: проект из ада]. Он счёл, что MPlayer сложно установить, и заявил, что разработчики были недружелюбны, а документация неполной и оскорбительной. Вам решать. Затем, он негативно упомянул Arpi в 10 Linux predictions for 2002[10 предсказаний о Linux на 2002]. В появившемся затем обзоре xine, названном A streaming media player for the rest of us[Потоковый проигрыватель фильмов для остальных] он продолжил раздувать спор. Иронично, но в конце этой статьи он цитирует интервью с Гюнтером Барцхом[Günter Bartsch], первоначальным автором xine, которое превосходно подытоживает ситуацию:

> However, he also went on to say that he was "surprised" by my column about Mplayer and thought it was unfair, reminding me that it is a free software project. "If you don't like it," Bartsch said, "you're free not to use it."

> [Однако, он также сказал, что он был "удивлён" моей колонкой о MPlayer'е и подумал, что это было бы неправильно напоминать мне, что это проект свободного программного обеспечения. "Если он вам не нравится", сказал Барцх, "Вы свободны не использовать его."]

Спустя почти два года, в октябре 2003, он написал другой обзор, названный Almost two years later in october 2003 he wrote another review called Mplayer revisited[Снова MPlayer] (неправильное написание сохранено). В этой статье он пришёл к таким заключениям:

> I would have to say that there have been improvements in the number of features, in performance, and in documentation. It's still not the easiest install in the world, especially for newbies, but it's a little better than it used to be.

> [Я должен сказать, что улучшения коснулись многих возможностей, производительности и документации. Это всё ещё не простейшая в мире установка, особенно для новичков, но это лучше, чем то, что было.]

и

> But more importantly, I didn't notice any recent comments about user abuse. I think I deserve some of the credit for that, even if I do say so myself. Arpi and the rest of the project team must feel that way too, because they have taken care to remember me in a special section of the documentation included in the tarball. Like I said at the start, some things haven't changed at all.

> Но, что более важно, я не заметил никаких комментариев о пользовательской ругани. Я полагаю, что я тоже заслуживаю похвалу за это, хотя мне и приходится говорить это самому. Arpi и остальные из команды, наверное, тоже так думают, поскольку они выделили мне специальную секцию в документации, включённой в архив. Как я сказал вначале, некоторые вещи совсем не изменились.

Мы бы не смогли лучше сформулировать наши чувства по отношению к Джо Барру: " Это всё ещё не лучшая исследовательская статья в мире, но она лучше, чем была.] [It's still not the fairest or best researched article in the world, but it's better than it used to be." Надеемся, что в следующий раз наши ожидания совпадут. Тем не менее, благодарность за зрелость относится только к нашему увеличивающемуся возрасту, и, может быть, утомлению от от воин флейма.