Zaphfc lässt sich nicht kompilieren

[sir-archimedes]

Hallo,

wenn ich versuche via "make loadNT" den Treiber für meine HFC-Karte zu kompilieren erhalte ich folgende Meldung:

server:/usr/local/src/bristuff-0.2.0-RC8h/zaphfc# make loadNT
make -C /usr/src/linux-2.6 SUBDIRS=/usr/local/src/bristuff-0.2.0-RC8h/zaphfc ZAP=-I/usr/local/src/bristuff-0.2.0-RC8h/zaptel-1.0.8 modules
make[1]: Entering directory `/usr/src/kernel-headers-2.6.11-1-686'
CC [M] /usr/local/src/bristuff-0.2.0-RC8h/zaphfc/zaphfc.o
/usr/local/src/bristuff-0.2.0-RC8h/zaphfc/zaphfc.c: In function 'hfc_findCards':
/usr/local/src/bristuff-0.2.0-RC8h/zaphfc/zaphfc.c:1000: error: invalid lvalue in assignment
make[2]: *** [/usr/local/src/bristuff-0.2.0-RC8h/zaphfc/zaphfc.o] Fehler 1
make[1]: *** [_module_/usr/local/src/bristuff-0.2.0-RC8h/zaphfc] Fehler 2
make[1]: Leaving directory `/usr/src/kernel-headers-2.6.11-1-686'
make: *** [linux26] Fehler 2
server:/usr/local/src/bristuff-0.2.0-RC8h/zaphfc#

Woran kann das liegen? Ich nutze Debian Etch und habe bevor ich versucht habe den Treiber zu kompilieren meine Distribution aktualisiert und habe daher den GCC 4. Kann es daran liegen?

Viele Grüße,
Dominik

 

[britzelfix]

@sir-archimedes

jajaja

Ich nutze Debian Etch

das läuft nicht stabil, nimm sarge/testing o. stable

ansonsten dann mit der HOWTO weiter:

http://www.ip-phone-forum.de/forum/viewtopic.php?t=21838


Gruß
britzelfix

 

[sir-archimedes]

Hallo,

ich nutze ja schon testing: sarge ist mittlerweile stable und etch ist testing. Eigentlich wird für Testing schon ziemlich gut gefiltert, was da rein kommt, und ich hatte bisher nie Probleme mit Debian Testing...

Das HOWTO hilft leider nicht groß weiter, da hier leider ebenfalls nur das Bristuff-Paket installiert/kompiliert wird, und daher der gleiche Fehler bei mir auch auftritt.

Interessant ist, wie die angemerkte Zeile in der zaphfc.c aussieht:

(ulong) hfctmp->fifos = (((ulong) hfctmp->fifomem) & ~0x7FFF) + 0x8000;

Ich frage mich, ob der aktuelle gcc es zuläst einer Variablen gecastet einen Wert zuzuweisen... Aber leider bin ich in C nicht sonderlich fit, als dass ich das jetzt korrigieren könnte.

mit

hfctmp->fifos = (((ulong) hfctmp->fifomem) & ~0x7FFF) + 0x8000;

kompiliert es, bringt mir aber eine Warnung. Ich müsste den rvalue also noch in einen Pointer casten, aber weiß gerade nicht, wie da die C-Syntax ist...

Vielleicht weiß das ja jemand anderes

Trotzdem kann ich damit den Treiber nicht laden! Ich probier jetzt aber mal weiter... Vielleicht bekomme ich es ja hin, indem ich * als Debian-Paket installiere - da ist ja auch zaptel, etc. mit dabei...

Gruß,
Dominik

 

[britzelfix]

@archimedes

ich nutze ja schon testing

was ist dann "Debian Etch" ?

Das HOWTO hilft leider nicht groß weiter

D.h. Du weißt im Grunde genommen wie man zum Ziel kommt, willst aber speziell hierfür eine Lösung.

(ulong) hfctmp->fifos = ((((ulong) hfctmp->fifomem) & ~0x7FFF) + 0x8000);

so geht's.

Trotzdem kann ich damit den Treiber nicht laden!

ja, ich hab's auch noch nie geschafft. Ich habe hier auch den
4.1'er, der kann auch "auto-vectorization".

Gruß
britzelfix

 

[sir-archimedes]

Hi,

cool, dass man so spät in der Nacht noch Antworten bekommt

Zum Thema etch/Testing: http://www.debian.org/releases/testing/
Da Sarge mittlerweile stable ist, heißt das jetzige (neue) Testing halt etch...

Das Problem war/ist, dass ich bequemerweise versucht habe * über die Debian-Pakete zu installieren, den zaphfc-Treiber aber nicht per Paket zum Laufen bekommen habe. Daher hat mir das Howto nicht direkt weitergeholfen, da man dort ja * auch selber kompiliert.

Tatsächlich ist es deprecated, wenn man als lvalue einer Zuweisung einen Cast hat. (Sagt mir gcc 3.3) Bei gcc 4 wird das nicht mehr unterstützt - daher auch der Fehler beim Kompilieren. Ich hoffe, dass das in zukünftigen Versionen berücksichtigt wird! Dieses "so geht's" stimmt somit nur bei älteren gcc-Versionen. Debian testing aber installierte mir standardmäßig den gcc 4.

Ich habe mir aber geholfen, indem ich jetzt gcc 3.3 als Standard eingestellt habe, dann habe ich mir komplett * neu inkl. Chan-Capi, zaphfc, etc. installiert/kompiliert und es tut!

Was aber nicht tut ist der Anschluss des Telefons an die hfc-Karte (im NT-Modus): Das Telefon meldet nur Störung und Asterisk selbst gibt auch keine Meldung aus (wenn ich den Hörer abnehme). Ich schließe das Telefon über einen (imho korrekt verkabelten) NTBA an die Karte an. Muss man da noch etwas konfigurieren, damit die Verbindung überhaupt geht, oder wo kann ich suchen?

Schönen Gruß,
Dominik

 

[britzelfix]

Da Sarge mittlerweile stable ist, heißt das jetzige (neue) Testing halt etch...

Ach so. Seltamer Name.

Tatsächlich ist es deprecated, wenn man als lvalue einer Zuweisung einen Cast hat. (Sagt mir gcc 3.3) Bei gcc 4 wird das nicht mehr unterstützt - daher auch der Fehler beim Kompilieren. Ich hoffe, dass das in zukünftigen Versionen berücksichtigt wird!

Ich weiß nicht ob man das schon so sagen kann. Netter währe es nämlich einen Kompatibilitätsmodus zu schaffen mit "-enable-deprecated" o.ä. Ich glaube sogar, daß es etwas änliches schon gibt. gcc war bisher immer sehr tolerant. Für strictes handling gibt es dann -ansi oder -Werror.

Dieses "so geht's" stimmt somit nur bei älteren gcc-Versionen. Debian testing aber installierte mir standardmäßig den gcc 4.

Du hast recht, es war mein Fehler. fifos ist "volatile void *". Das in ein Struct zu packen, mag künstlerische Freiheit sein, aber ich kenne keine Verwendung dafür. Der gcc-3.3 sagt dazu auch "warning: useless keyword or type name in empty declaration"

was nun wirklich geht ist:

// 1)
hfctmp->fifos = (volatile void *)((((ulong) hfctmp->fifomem) & ~0x7FFF) + 0x8000);
// 2) oder Schritt für Schritt 
{
  ulong *fifos = (ulong *)&hfctmp->fifos;
  ulong fifomem = (((ulong) hfctmp->fifomem) & ~0x7FFF) + 0x8000;
  *fifos = fifomem;
}

Es würde mich noch interessieren wie man die gcc-4.X compilierten module zum laufen bringt. Das sollte dann bei Etch doch möglich sein.

Gruß
britzelfix

 

[sir-archimedes]

Ich weiß nicht ob man das schon so sagen kann. Netter währe es nämlich einen Kompatibilitätsmodus zu schaffen mit "-enable-deprecated" o.ä. Ich glaube sogar, daß es etwas änliches schon gibt. gcc war bisher immer sehr tolerant. Für strictes handling gibt es dann -ansi oder -Werror.

Kann gut sein, dass das geht, nur kenne ich mich nicht mit gcc aus - daher weiß ich nicht, was man steuern kann und was nicht. Ich habe nur gemerkt, dass man mit den Standardeinstellungen nicht weiterkommt!

Du hast recht, es war mein Fehler. fifos ist "volatile void *". Das in ein Struct zu packen, mag künstlerische Freiheit sein, aber ich kenne keine Verwendung dafür. Der gcc-3.3 sagt dazu auch "warning: useless keyword or type name in empty declaration"

was nun wirklich geht ist: [...]

Ah sehr gut, danke Ich habe es aber trotzdem einfach mit dem gcc3.3 compiliert und gut wars, denn:

Es würde mich noch interessieren wie man die gcc-4.X compilierten module zum laufen bringt. Das sollte dann bei Etch doch möglich sein.

Das ist nämlich noch das Problem: wenn ich das Modul mit gcc4 kompiliert habe, bekomme ich die Meldung, dass ich das KernelModul nicht laden kann, da es das falsche Format hat. Mein Kernel (2.6.8) ist mit gcc3.3 kompiliert - daher müssen die Kernel-Module (wie zaphfc) auch mit der gleichen gcc-Version kompiliert werden. Aber ich gehe mal davon aus, dass sobald der Übergang von gcc3.3 auf gcc4 abgeschlossen ist, auch der Kernel mit gcc4 kompiliert wird. Denn dann muss man sogar Module, wie das zaphfc mit gcc4 kompilieren!

Wenn ich mich da jetzt vertue, bitte ich um Verbesserung

Achja: ich habe jetzt den kompletten Asterisk-Kram, der als Debian-Paket vorlag rausgeschmissen (bis auf die rxfax-Geschichten) und selbstkompiliert. Damit habe ich jetzt eine HFC-S-Karte zusammen mit einer AVM-Fritz-PCI2-Karte zum Laufen bekommen. Funktioniert für die, die es interessiert auch wunderbar ohne hörbare Klangprobleme/Echo, etc. Da ich die Karten über eine Raise-Karte eingebaut habe, könnte es auch gut sein, dass sie den gleichen Interrupt haben - aber auch das verursacht keine Probleme bei mir.

Gruß,
Dominik

 

[britzelfix]

Denn dann muss man sogar Module, wie das zaphfc mit gcc4 kompilieren!

sieht ganz danach aus. Es wird dann ein ziemliches Chaos entstehen weil's von solchen "Fehlern" noch eine ganze Menge gibt.

Wenn ich mich da jetzt vertue, bitte ich um Verbesserung

Hab's auch selbst noch nicht ausprobiert.

Achja: ich habe jetzt den kompletten Asterisk-Kram, der als Debian-Paket vorlag rausgeschmissen

Hab's noch auf einer anderen Kiste für mISDN laufen.

Gruß
britzelfix