hmmm.
az összes 1.x.x alsa-oss driver ugyanezzel dob ki, a 0.9.1. viszont lefordult, és megy is.
érdekes… 😕 😕 😕

Jó a az ötlet, bár nem találom sehol milyen gcct kíván. a letöltött dokumentben nincs, az oldalon meg szintén nem tudom 😀
még nézem azért egy picit, hátha én leszek a végén az okosabb.
próbáltam felfogni mi a baja, szerintem teljesen OK függvényhívást használ, semmi nem too many ott… ami too many, az a függvény neve…

akkor ez sem lehet gond. az van fent. ráadásnak a 0.91-ben ugyanolyan „to many” a paraméter. egy centivel sem rövidebb… 😀

köszi MeheMad… felraktam azt ami megy, úgyhogy már én is csak kiváncsi vagyok… megtámadom még anjuta alatt, hátha mond valami okosat, de már csak kiváncsiságból. 😀 hátha tanulok valami okosat… 😀

Bbt:
„akkor ez sem lehet gond. az van fent.”
ebben az esetben ez meg keves, mert a kernel tisztan „Makefile” alapon fordul, tehat nem lehet se autoconfigos konfoguralasonkenti, se ‘export CC=’ jellegu idegelenes aterest alkalmazni: at kell irni a Makefilet, hogyha az alap gcctol elterot akarsz alkalmazni;
eloszor nezd meg milyen gcc valtozato vannak fenn: ‘ls /usr/bin/gcc*’
majd melyik Makefleokban szerepel a gcc kozvetlenul (mert mar a forditas elejen kiexportalja a CC es HOSTCC valtozoba, tehat eleg ezt az exportalos sort atirni): ‘grep „= gcc” * -r’
imho eleg a legalso szinten a Makefilet atirni, de sohase lehessen tudni;
tehat ilyen sorok legyenek benne:
HOSTCC = gcc-2.95
CC = $(CROSS_COMPILE)gcc-2.95

egyebkent elo szoktak fordulni kisebb kellemetlensegek, pld legutobbi nalam: a 2.4.20-as kernelhez keszult G8 exec-shield nem fordult 2.95-os gcc-vel, viszont 3.3.0-val mg a kernelforditas hasalt el a cryptografic resznel; de par nappal kesobb kijott a G9, ami ment 2.95-tel es azota is uzemel;