A rilízinfóval nem megyünk most semmire, az architektúra kellene uname -m, mert „wrong ELF class: ELFCLASS64”, meg az őt meghívó program architektúrája, mert nagyon úgy néz ki, hogy egy 32 bites (vagy más architektúrájú) program akar meghívni egy 64-biteset.

Nem, mert ez egy forrás.Az a kérdés, hogy hogy lett nálad 64 bites forrásból, amikor - úgy néz ki - még a kerneled sem az.Ha a kerneled az lett volna, az ulogd-d 32 bites, skkor még el tudnám képzelni.

Vagy rosszul paramétereztél valamit, vagy esetleg valaki rajtahagyott valami szemetet (bár ez kevésbé valószínű).Célszerű egyébként kiadni egy make distclean-t, ha esetleg valami ott maradt. Ill. make clean-t, minden forrás módosításakor, mert anélkül esetleg linkelési hibát, vagy seggfoltolást lehet elérni.

Elvileg miért ne lehetne másik CPU-ra fordítani. Nem lehet mindent Assemblerrel kezdeni, vagy mi. 😀Tehát, ha szépen magdtad neki valami nem ahhoz szóló súgó szerint, akkor... (ráadásul, ha nincs függősége, vagy megvan forrásban, akkor végre is lehet hajtani még egy statikus linkelést is)A többit meg jó tudni, mert úgy van felépítve a rendszer, hogyha félbeszakad, akkor onnan folytatja, ahol megszakadt a többit időbélyeg szerint csak ellenőrzi. Na most, ha megszűnik egy változó, de az obj-ban már benne van a hivatkozás és ugye az obj nem törlődik, a linker meg nem tudja mi van a forrásban, akkor a legjobb eset, hogy nincs meg a simbólum és hibát dob ki. De, ha a mérete típusa változik, akkor ugye szívás, mert nem dob ki hibát, hanem esetleg seggfoltolni fog.(Bár azt mondjuk kizárnám, hogy valami előre konfigolt cuccot "árulnának", az már másnak is feltűnt volna.)