Developerzy 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ładami są MySQL i avifile. Inne, interesujące linki: Krótka wiadomość o jądrze 2.4.17 i Forum Voy. MPlayer ucierpiał również 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 jeżeli 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 leży w fakcie, że cicho ignoruje on cały blok assemblera. 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, w rzeczy samej, poprawiła się, ciągle jednak dostajemy raporty o błędach na nasze listy mailingowe, które znikają wraz z przejściem na inny kompilator. W każdym bądź 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 mailingowej, ponieważ mamy już więcej 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 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ło 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 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 brak stabilności jest podyktowany wadliwymi chipami 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, doradzana jest Ci instalacja najnowszej wersji sterowników nVidia i/lub kupno nowej płyty głównej lub poproszenie o otwarte sterowniki. W każdym bądź 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 mniej niż 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ń. Dalej, negatywnie wspomniał o Arpi'm 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że, mówił dalej, że był "zdziwiony" moją kolumną o MPlayerze i mówił mi, że to niesprawiedliwe, 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 sobie tak wmawiam. Arpi i reszta zespołu pracującego nad projektem muszą czuć to samo, ponieważ zatroszczyli się i wspomnieli o mnie w specjalnym rozdziale ich dokumentacji załą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.