Nvidia 64 bitowy driver twierdzi że system jest 32bit :\

[log_out]

Po zmianie sprzętu na Athlona64 + GF7600GS stwierdziłem że będe mógł wkońcu zainstalować sobie 64 bitowy sterownik niestety przy instalacji krzyczy że system jest 32 bit !

Od czego to zależy ?? kernel mam przekompilowany pod 64 bit, glibce też... może to chodzi o xorg ?

co dziwne uname -p pokazuje mi że mam athlon-4 ?

[jacol]

Witam.
log_out jak chciałbym kompilować programy na avr lub inny procesor to postarał bym się o narzędzia: gcc libc i binutils ewentualnie gdb. Pozdrawiam jacol
PS. Ktoś już o tym pisał na forum. Temat jest mi bliski z powodu tego że ostatnio przygotowywałem zestaw narzędzi dla arm i avr.

[tomek-o]

Nie masz kompletnie 64-bitowego system (w każdym razie Twoja Mozilla jest kompilowana pod i686). Przyczyn może być wiele - 32-bitowe X-y, gcc który nie generuje kodu 64-bit, etc. Moim zdaniem nie ma co się bawić w samodzielne usześdziesięcioczterbitowianie systemu. Trzeba wziąć gotową dystrybucję wspierającą AMD64 i działać w ten sposób. 64-bitowość przy zachowaniu kompatybliności to nie jest łatwa sprawa. Moim zdaniem lepiej wykorzystać gotowe rozwiązanie, niż próbować samemu poprawiać rzecz, która wbrew pozorom wymaga bardzo dokładnych przemyśleń.

[log_out]

Nie masz kompletnie 64-bitowego system (w każdym razie Twoja Mozilla jest kompilowana pod i686)

tyle to i ja wiem

gcc który nie generuje kodu 64-bit

tzn ?? mi się wydawało że jak się da -march=athlon64 to automatycznie program/biblioteka staje się 64 bitowy

Trzeba wziąć gotową dystrybucję wspierającą AMD64 i działać w ten sposób.

Problem w tym że nie ma Slackware pod 64 bity, zresztą połowa systemu i tak jest kompilowana przezemnie więc nie wiem czy to ma jakiś sens...

[Phantom_Warrior]

Problem w tym że nie ma Slackware pod 64 bity (...)

Poczytaj o SLAMD64...

EDIT:

Link do Slamd64

[log_out]

Poczytaj o SLAMD...

Tak, znam ten projekt ale jest on zawsze zapóźniony w stosunku do Slacka no i autor niepoważnie hobbystyczne do niego podchodzi robiąc "przerwe wakacyjną" w rozwoju systemu, wole nie pakować się w coś co za 3-4 miesiące może mu się całkowicie znudzić ...

[Phantom_Warrior]

A Twój problem polega na tym, że nie masz 64 bitowych bibliotek...

[Dario]

Może weź sobie pare kawałków z innego "eksperymentu" przeportowania Slacka na 64bity, o wakacjach tam nic nie piszą tylko później nie marudź, że ci np. java w przeglądarce nie chce działać (może już działa).
P.S. Cieszę się że kupiłem zwyczajne P4, choć kusiło mnie amd64

[Phantom_Warrior]

32 bity rulezzz

[nOrNIc]

Jak lubisz kompilowac sobie na 64 bit to czeka Cie dluga droga i ogrom problemów z kompatybilnoscia. Mialem to samo i zrezygnowalem. Doszedlem do jednego wniosku, jak chcesz miec 64bitowy system to zacznij od bazy 64 bit. Innymi slowy zamiast przekompilowywac wszystkie programy na athlon64 to postawilem slamd64 pozmienialem konfigi podobne do tych w starym systemie i dopiero przekompilowywalem sobie all co mnie interesuje.

Teraz i tak mam przekompilowane dopiero 50% systemu ale przy najmniej baza byla na 64bit. Znacznie to sprawe ulatwia. Przy konfiguracji slamd64 mialem duzo bajerow i ostre problemy zwiazane z kompatybilnoscia, ale nie ma tego zlego co by na dobre nie wyszlo . Wiesz lubie system perfekcyjny i jak na razie idzie dobrze. (na poczatku ostro sie na slamd64 powku*lem)

Na start najlepiej przekompilowac toolchain w kolejnosci: gcc->binutils->gcc->glibc i dopiero kernel + others.

Co do tych sterownikow to calkiem mozliwe ze sa to X'y - sterownik bodajze wymaga xliba. Dla testu sciagnij sobie pakiety x11*-x86_64-1.tgz ze slamd64 i sprawdz czy driver sie skompiluje, wtedy bedziesz mial pewnosc ze to xorg i przekompilujesz po swojemu.

--EDIT--
@Dario
Nie ma jeszcze 64bit javy ani flash'a i extensions pod ff sa w wiekszosci uzaleznione od 32bit. Na 64 bit nie ma rowniez mplayer'a, wiec na dzien dziesiejszy kompatybilnosc z systemem 32bit to koniecznosc!

[tomek-o]

Rzecz w tym, ze są dwa podejścia do problemu 64-bitów.
Pierwsze to całkowite pożegnanie się z 32-bitowym światem. Tak robi np. OpenBSD na AMD64/SPARC64. Wszystko jest 64-bitowe i niekompatybilne z tym 32-bitowym. Tak można też skompilować Linuksa (i Ty tak właśnie robisz). To najlepsze rozwiązanie, ale jest jeden drobny problem - brak binarnej kompatybliności. Jak nie będzie binarki programu X na 64 bity, to się go nie uruchomi. I koniec, i kropka.
Drugie to pozostawienie 64-bitowego jądra z obsługą kodu 32-bitowego. Tak jest w Solarisie na amd64 i sparcv9 (to chyba prekursor tego rozwiązania) i na Linuksach (np. SLAMD64). Pełnej binarnej kompatybilności nie ma, bo moduły jądra muszą być 64-bitowe. Ale poprzez trzymanie dwóch wersji bibliotek (na Solarisie jest to ładnie uporządkowane: jeżeli 32-bitowe są w katalogu /usr/lib, to 64-bitowe siedzą w /usr/lib/64, będącym linkiem do /usr/lib/sparcv9 bądź /usr/lib/amd64, natomiast które katalogi brać przy linkowaniu, to już zależy od zmiennych środowiskowych LD_LIBRARY_PATH i LD_LIBRARY_PATH_64) zapewnia się binarną zgodność aplikacji. Tak więc zadziała binarny Skype, da się skompilować MPlayera... Niestety, mamy narzut na przestrzeń dyskową i zajętość pamięci operacyjnej (dłuższe wskaźniki). W Solarisie 64-bitową wersję mają tylko te programy, które mogą zutylizować więcej niż 4GB pamięci lub są wydajniejsze od 32-bitowych. W Linuksach na x86-64 niestety na 64 bity kompilowane jest wszystko jak leci.
Po co to piszę? Żebyś uświadomił sobie, że pierwsze podejście jest dla Ciebie osiągalne, ale da marne rezultaty, przez brak kompatybilności binarnej. Drugie jest niestety wysoce skomplikowane, wymaga wielu przemyśleń i dobrej organizacji systemu. Dlatego warto skorzystać z gotowych rozwiązań. Linuks jest kiepsko dostosowany do architektury AMD64, to fakt i jeżeli nie ma powodów, by z niej korzystać, to absolutnie nie warto, bo brak zysków, a potencjalnie mogą pojawić się kłopoty. Ale moim zdaniem lepiej korzystać z SLAMD64 (który de facto jest 64-bitowym Slackwarem, to prawie identyczny system, tylko przekompilowany i ze zdublowanymi bibliotekami), nic użerać się z własnymi przeróbkami. Sam korzystam z SLAMD64 i jestem zadowolony, choć pewnie byłbym bardziej, gdyby Slackware oficjalnie wspierał AMD64, bo to niewątpliwie obecnie przyszłość.

[nOrNIc]

Nom co do reorganizacji systemu to jest jeszcze metoda gentoo to znaczy;
lib jest linkiem do katalogu lib64 a jak chcesz 32bitowy system to sie podmienia linka na lib32, ale ten projekt chyba byl zarzucony nie pamietam.

Ja u siebie po wielu komplikacjach - przez co nadal uwazam ze slamd w wersji podstawowej jest bardzo niedopracowany! Duzo czasu zajela mi jego zmiana. Moja organizacja systemu to:

biblioteki 64 bitowe w katalogach /lib64 /usr/lib64 a 32 bitowe po staremu w /lib /usr/lib.
Wiekszosc programow przekompilowalem do tego wygladu i jeszcze czesc mi zostalo (cholerny slamd ma je pomieszane). Osiagam w tym momencie pelny - normalnie dzialajacy system 64bitowy, ale po krotkim czasie zaczely sie problem, ze ten prog nie wspiera 64bit ze tamten prog nie wspiera i zaczelem sie ostro wkurzac. Moja kompatybilnosc to jest przerobienie swoich starych paczek na system 32 bit (wywalenie z nich wszystkiego poza lib'ami i ewentualnie jakies binarki) instalacja tych paczek, przez co mam czysto w systemie ale niektore liby sa zdublowane (czesc na 32bit czesc na 64). Aby pozbyc sie kilku warningow przy starcie aplikacji 32bit dorobilem jeszcze /usr/share32 i napisalem odpowiedni skrypcik ktory eksportuje wszystkie potrzebne katalogi przed uruchomienie takie jak polozenie configow pango, gtk, czy 32bit locali do X'ow. Niezbedny jest rowniez programik linux32, emulujacy srdowisko 32bitowe (organizacja pamieci + arch podawany do uruchamianego programu).

Dzieki temu zyskalem 64bitowy system + mozliwosc uruchamiania i kompilacji wszelkich programow pod 32bit. Tak normalnie system jest w pelni 64bit. Oczywiscie nalezy kompilowac pod takim systemem 32bit aplikacje w odpowiedni sposob

[log_out]

Nie powiem troche mnie to wszystko wystraszyło

czyli rozumiem że jak "sobie skompilowałem" glibce na athlona64 to one tak naprawdę nie są 64 bitowe ? czy źle to rozumuje

No ale mam pytanie - jakie są konkretne problemy ze SLAMD64 ?? bo wszyscy piszą że mają "przejścia" z nim ale nic konkretnego ??

[nOrNIc]

Nie powiem troche mnie to wszystko wystraszyło

czyli rozumiem że jak "sobie skompilowałem" glibce na athlona64 to one tak naprawdę nie są 64 bitowe ? czy źle to rozumuje

No ale mam pytanie - jakie są konkretne problemy ze SLAMD64 ?? bo wszyscy piszą że mają "przejścia" z nim ale nic konkretnego ??

hmmm co do glibcow to nie wiem, ale -march=athlon64 ma zawarty w sobie -m64, czyli o ile nie podasz -m32 to powinien powstac kod na 64bit- no chyba ze przy kompilacji wywalil Ci jakies bledy. Nie wiem dokladniej bo nie testowalem w ten sposob - startowalem z gcc 64bit

Slamd czy jest dobry zalezy od tego jak gleboko w system chcesz wnikac, jak ci wystarcza zwykle chodzenie po systemie, iksy i w ogole zwykly desktop to nie zobaczysz roznicy

Roznica bedzie jak bedziesz chcial sobie poukladac all, lub zaczac kompilowac jakies dziwne programy. Jak bedziesz duzo kompilowal wyjda ci rozne mary.

A w ogole slamd64 jest tworzony hobbystycznie. Dopoki nie zainstalujesz sobie to sie nie przekonasz. Na poczatku nie widzialem w nim wad, dopiero w miare korzystania sie ujawnialy.