Deweloperzy wyrywają sobie włosy GCC 2.96 Zarys historyczny: GCC z serii 2.95 jest oficjalnym wydaniem GNU, a jego wersja 2.95.3 jest najbardziej wolna od błędów. Nigdy nie odnotowaliśmy problemów przy kompilacji, które moglibyśmy przypisać gcc-2.95.3. Zaczynając od Red Hat Linuksa 7.0, Red Hat dołączył poważnie zmodyfikowaną wersję CVS GCC do swojej dystrybucji i nazwał ją 2.96. Stało się tak, ponieważ GCC 3.0 nie było jeszcze ukończone, a potrzebowano kompilatora, który współdziałałby dobrze z wszystkimi platformami jakie były obsługiwane, włączając w to IA64 i s390. Dystrybutor Mandrake również poszedł w ślady Red Hata i zaczął dołączać GCC 2.96 do serii Linux-Mandrake 8.0. Oświadczenie: Zespół GCC wyparł się jakichkolwiek powiązań z GCC 2.96 i wystosował oficjalną odpowiedź na GCC 2.96. Wielu developerów ze świata zaczęło mieć problemy z tym kompilatorem i zarekomendowali inne. Przykłady to MySQL i avifile. Inne interesujące linki: Krótka wiadomość o jądrze 2.4.17 i Forum Voy. MPlayer również ucierpiał z powodu okresowych problemów, które zostały rozwiązane przez przesiadkę na inną wersję GCC. Kilka projektów rozpoczęło implementację obejść dla pewnych spraw związanych z 2.96, ale my postanowiliśmy nie naprawiać błędów innych, szczególnie, że niektóre obejścia mogą ujemnie wpływać na wydajność. GCC 2.96 nie pozwala na użycie symbolu | (pipe - potok) w komentarzu assemblera, ponieważ obsługuje zarówno składnię Intela jak i AT&T, a symbol | jest stosowany w wariancie Intela. Problem polega na tym, że cały blok assemblera jest po cichu ignorowany. Rzekomo zostało to już naprawione i GCC wyświetla ostrzeżenie zamiast pomijania tego bloku. Teraźniejszość: Red Hat twierdzi, że GCC 2.96-85 i kolejne zostały już poprawione. Sytuacja rzeczywiście poprawiła się, ciągle jednak dostajemy raporty o błędach na nasze listy dyskusyjne, które znikają wraz z przejściem na inny kompilator. W każdym razie, nie ma to już znaczenia. Mamy nadzieję, że dojrzewające GCC 3.x na dobre zakończy tę sprawę. Jeżeli chcesz kompilować z 2.96, przekaż flagę skryptowi configure. Pamiętaj, że możesz wtedy liczyć tylko na siebie i nie zgłaszaj żadnych błędów. Jeżeli to zrobisz, zostanie odebrany Ci dostęp do naszej listy dyskusyjnej, ponieważ mamy już bardziej niż dość bezsensownych kłótni na temat GCC 2.96. Proszę, zostaw tę sprawę w spokoju. Jeżeli masz problemy z GCC 2.96, możesz pobrać paczki 2.96-85 z serwera ftp Red Hat lub skorzystać z pakietów 3.0.4, oferowanych z wersją 7.2 i kolejnymi. Możesz również ściągnąć pakiety gcc-3.2.3-11 (nieoficjalne, ale działają dobrze) i zainstalować je razem z gcc-2.96, które już masz. MPlayer wykryje je i użyje 3.2 zamiast 2.96. Jeżeli nie chcesz albo nie możesz użyć binarnych paczek, poniżej znajdziesz informacje, jak skompilować GCC 3 ze źródeł: Wejdź na stronę z serwerami lustrzanymi GCC i ściągnij gcc-core-XXX.tar.gz, gdzie XXX to numer wersji. W pliku znajduje się kompletny kompilator C, który wystarczy dla MPlayera. Jeżeli chcesz mieć również C++, Java albo inne z zaawansowanych możliwości GCC, gcc-XXX.tar.gz może bardziej pasować do twoich potrzeb. Rozpakuj archiwum, wykonując tar -xvzf gcc-core-XXX.tar.gz GCC nie jest budowane w katalogu źródłowym jak większość programów, ale potrzebuje katalogu kompilacji poza katalogiem ze źródłami. Będziesz musiał stworzyć katalog przez mkdir gcc-build Dalej możesz przejść do procedury konfiguracyjnej i katalogu budowy, ale musisz skonfigurować z katalogu źródłowego: cd gcc-build ../gcc-3.XXX/configure Skompiluj GCC, wykonując tę komendę w katalogu kompilacji: make bootstrap Teraz możesz zainstalować GCC (jako superużytkownik), wpisując make install Dystrybucja binariów MPlayer zawierał wcześniej źródła z projektu OpenDivX, który zabrania redystrybucji binariów. Kod ten został usunięty w wersji 0.90-pre1, a pozostawiony plik divx_vbr.c, który pochodzi ze źródeł OpenDivX, został objęty licencją GPL przez jego autorów w wersji 0.90pre9. Możesz teraz bez obaw tworzyć pakiety binarne. Kolejną przeszkodą przy redystrybucji binariów była optymalizacja dla konkretnej architektury CPU podczas kompilacji. MPlayer obsługuje wykrywanie CPU podczas uruchamiania (podaj opcję dla skryptu configure). Jest ona domyślnie wyłączona, ponieważ wymaga poświęcenia małej części mocy obliczeniowej procesora. Jednak możliwe jest teraz tworzenie binariów, które będą działały na różnych typach procesorów kompatybilnych z Intelem. nVidia Nie podoba nam się fakt, że nVidia dostarcza wyłącznie sterowniki binarne (dla XFree86), które często zawierają błędy. Dostaliśmy wiele zgłoszeń na mplayer-users o ich błędach, marnej jakości, braku stabilności oraz słabym wsparciu dla użytkownika i eksperta. Wiele z tych problemów/kwestii pojawia się ciągle. nVidia skontaktowała się z nami ostatnio i stwierdziła, że te błędy nie istnieją, a przyczyną braku stabilności są wadliwe układy AGP, nie otrzymali również żadnych zgłoszeń o błędach w sterowniku (takich jak purpurowa linia). Jeżeli masz problem ze swoją kartą nVidia, radzimy zainstalować najnowszą wersję sterowników nVidia i/lub kupno nowej płyty głównej lub poprosić nVidię o otwarte sterowniki. W każdym razie, jeżeli używasz sterowników binarnych nVidia i stajesz przed problemami z nimi związanymi, bądź świadom, że nie otrzymasz zbyt dużej pomocy z naszej strony, ponieważ nie mamy dużej możliwości jej udzielenia. Joe Barr Joe Barr stał się mało popularny w grudniu 2001, pisząc niezbyt pochlebną recenzję MPlayera zatytułowaną MPlayer: Projekt z piekła rodem. Miał problemy z jego instalacją. Stwierdził również, że developerzy byli mało przyjaźni, a dokumentacja niekompletna i ubliżająca. Sam oceń. Następnie negatywnie pisał o Arpim w swoich 10 prognozach dla Linuksa na rok 2002. W podobnej recenzji xine zatytułowanej Strumieniowy odtwarzacz mediów dla reszty z nas ciągle wzbudzał kontrowersje. Jak na ironię, pod koniec swojego artykułu cytuje krótką wymianę zdań między nim a Günterem Bartschem, twórcą xine, która idealnie podsumowuje całą sprawę:
Jednak powiedział też, że był "zaskoczony" moim artykułem o MPlayerze i uważa go za niesprawiedliwy, przypominając, że jest to projekt wolnego oprogramowania. "Jeśli Ci się nie podoba," powiedział Bartsch, "nie ma przeszkód, żebyś go nie używał."
Prawie 2 lata później w październiku 2003 napisał kolejną recenzję zatytułowaną Mplayer raz jeszcze. Zawarty jest w niej następujący wniosek:
Muszę przyznać, że znacznie zwiększyła się liczba możliwości, poprawiła się wydajność i dokumentacja. Ciągle instalacja nie jest najłatwiejsza na świecie, szczególnie dla początkujących, ale jest trochę lepiej niż było.
i
Ale co najważniejsze, nie dochodzą do mnie komentarze o oburzeniu użytkowników. Myślę, że należy mi się za to uznanie, nawet jeżeli tylko ja tak twierdzę. Arpi i reszta zespołu pracującego nad projektem muszą uważać tak samo, ponieważ zatroszczyli się o wzmiankę o mnie w specjalnym rozdziale ich dokumentacji dołączonej w pliku tar. Jak mówiłem na początku, niektóre rzeczy się nie zmieniają.
Nie możemy sprecyzować naszego stanowiska wobec Joe Barr'a lepiej: "Ciągle nie jest to najuczciwszy i najlepiej opracowany artykuł na świecie, ale jest lepszy niż kiedyś." Mamy nadzieję, że kiedyś przypadniemy sobie do gustu. Jednak uznanie za dojrzałość, możemy tylko przypisać starzeniu się i po części zmęczeniu bezsensownymi kłótniami.