[Openhorst-Firmware] Projekt Horstbox mit Asterisk 1.6 od. 1.4 (kein analog)

[potc]

Hallo,
neue Anpassung im SVN.
Alter Aufbau des Systemverzeichnisses

Kann selber erst am Donnerstag testen.

peter

 

[freeland88]

Hallo!

Bei mir bricht der Build-Prozess der aktuellen version mit folgender Fehlermeldung ab:

gcc -o make_at_dictionary ../src/make_at_dictionary.c -DHAVE_CONFIG_H -I../src
/tmp/ccYiP7sQ.o: In function `trie_node_create':
make_at_dictionary.c.text+0xe): undefined reference to `rpl_malloc'
/tmp/ccYiP7sQ.o: In function `trie_create':
make_at_dictionary.c.text+0x51): undefined reference to `rpl_malloc'
collect2: ld returned 1 exit status
make[2]: *** [make_at_dictionary] Error 1
make[2]: Leaving directory `/home/horst-trunk/spandsp-0.0.6/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/horst-trunk/spandsp-0.0.6'
make: *** [spandsp_install] Error 2

Funktioniert der Build bei jemandem oder ist er fehlerhaft?

gruss

 

[rmh]

Bei mir momentan ebenfalls fehlerhaft. Geduld ...

 

[potc]

Einfachste Lösung,
erste in der scripts/config.mk das spandsp 6 gegen spandsp 5...

peter

 

[potc]

So,
habe nochmal alles bei mir gecleant, mit svn verglichen und neu gebaut.
Geht alles durch. Muss also ein Problem in euerer Systemkonfiguration sein da dieser Modul nicht mit den buildroot utilities sondern den lokalem gcc gebaut wird.

Nur der nvramd macht Probleme, ohne diesen geht der ganze Bootprozess derzeit schief.

Muss ich noch genauer schauen

peter

 

[potc]

So,
bei mir läuft nun alles durch und der Build funktioniert auch auf der Horstbox.

Asterisk ist auf 1.6.2.9 hochgezogen

und die Load im WebIF geht auch immer brav runter


Achja,
habe im Forge die aktuelle Version auch als Image hinterlegt

peter

 

[freeland88]

hallo!

ich habe es mit der neuesten version probiert. leider habe ich immer noch das selbe problem. bei dem versuch auf spansp-0.0.5 umzustellen (config.mk) kommt ein gleicher/aehnlicher fehler.

make -C /home/horst-trunk/spandsp-0.0.6 install
make[1]: Entering directory `/home/horst-trunk/spandsp-0.0.6'
Making install in src
make[2]: Entering directory `/home/horst-trunk/spandsp-0.0.6/src'
gcc -o make_at_dictionary ../src/make_at_dictionary.c -DHAVE_CONFIG_H -I../src
/tmp/ccUObnJA.o: In function `trie_node_create':
make_at_dictionary.c.text+0xe): undefined reference to `rpl_malloc'
/tmp/ccUObnJA.o: In function `trie_create':
make_at_dictionary.c.text+0x51): undefined reference to `rpl_malloc'
collect2: ld returned 1 exit status
make[2]: *** [make_at_dictionary] Error 1
make[2]: Leaving directory `/home/horst-trunk/spandsp-0.0.6/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/horst-trunk/spandsp-0.0.6'
make: *** [spandsp_install] Error 2

was koennte ich hier falsch machen? oder was koennte mir hier fehlen?

danke!

 

[rmh]

Kann ich bestätigen, nach einigen Abfragen zur Konfigruration bricht der Build bei mir mit selbigem Fehler ab. Kann mich aber erst am WE ernsthaft mit der Box beschäftigen. Vielleicht haben wir Glück und potc schaut vorher nochmal nach.

 

[horatio42]

Hi potc,

ich habe versucht den aktuellen SVN trunk from scratch zu bauen, bin aber ueber das fehlende
patch.classpath098
gestolpert. Koenntest Du das noch nachreichen?
Ausserdem ist mir aufgefallen dass in der config.mk noch das patch fuer kernel 2.6.32 verwendet wird, im archive ist aber ein patch fuer 2.6.34 vorhanden, das auch "passender" konfiguriert ist. War das ein Versehen oder beabsichtigt?

Danke & Gruss,
H.

EDIT: mir ist auch noch aufgefallen dass die libpri in der in config.mk spezifizierten Version nicht mehr existiert (zumindest nicht unter dem angegebenen link). Die Version libpri-1.4.11 in der config.mk wurde anscheinend durch libpri-1.4.11.2 ersetzt. Diese kompiliert aber auch erstmal ohne Probleme.

EDIT2: Ich habe mir classpath selbst soweit gehackt dass es wieder kompilierte. Bei mir läuft dann der build soweit durch. Allerdings funktionieren bei diesem build ssh -logins nicht mehr, ich kriege eine Fehlermeldung "PTY allocation request failed on channel 0". scp funktioniert aber noch. Googleln behauptet dass es ein Problem mit dem pts device system gibt wenn man diese Fehlermeldung hat, es scheint dort aber alles wie gehabt zu sein, kein Unterschied zu meiner vorherigen Version. devpts ist gemounted und das /dev/pts Verzeichnis existiert. Kann das jemand reproduzieren?

 

[potc]

@horatio42
Das mit dem channel habe ic auch.
Das ist ein Problem aus dem buildroot, der dropbear will auf einmal die alten /dev/pt?? haben da hat sich die config wohl falsch zusammengabut.

@rmh u. @freeland
Euer Problem ist eine fehlende Library im lokalen system und nicht im buildroot, toolchain komplex.

Baut mal folgenden Tip in das scrip für den build von spandsp ein:

This is just autotools stupidness, which will produce the results you describe on some non-glibc systems (e.g., uClibc). If you give us some specifics (e.g., platform, c library, whether you are cross-compiling, what tutorial you are following, where you got your source, etc.), we might better help you.

If you try something like this
Code:

ac_cv_func_malloc_0_nonnull=yes ./configure --with-gnu-ld

peter

 

[potc]

So,
dropbear und damit ssh zugriff von außen sollte wieder gehen.

Btw. scp ging die ganze zeit.
Hat jemand wg. dem rpl_malloc den fix getestet ?

Als nächstes werde ich den neuen chan_lcr einbauen.
Evtl. geht ja dann die ISDN Front besser.

peter

 

[rmh]

@rmh u. @freeland
Euer Problem ist eine fehlende Library im lokalen system und nicht im buildroot, toolchain komplex.

Hallo potc,
bist du sicher, dass eine lokale library fehelt? Für mich sieht es so aus als würde eine lokale Version von libtiff.so, anstatt der CC Version für die ARM Plattform (aus dem Verzeichnis $(ROOTFS)/usr/lib/) verwendet werden. Ist hier vielleicht der Hund begraben?

Deine Codeschnipsel im spandsp.mk haben leider nicht viel gebracht. Drei unterschiedliche Maschinen, immer die gleiche Meldung: :noidea:

/usr/lib/libtiff.so: could not read symbols: File in wrong format

Gruß
R.

EDIT: Sorry, eben ist mir aufgefallen, dass bei mir eine andere Fehlermeldung kommt, als bei freeland88. Zwar ebenfalls in Verbindung mit spandsp, aber eben speziell libtiff betreffend.

 

[potc]

@rmh
Ja das blöde libtiff hat bei mir früher auch Stress gemacht.
Wenn ich eine andere Variante im configure von spandsp teste geht es bei mir nicht.
Aber du kannst einfach die 0.0.5 nehmen. Das neue spandsp braucht du nur wenn du T.38 Fax machen willst.
Evtl. kannst du mal ein bisschen mehr von den Ausgaben vor der Fehlermeldung zeigen.

Evtl. mach mal beim configure das disable-rpath raus.

peter

 

[potc]

So,
ich hab mal ein bisschen mit dem neusten mISDN gespielt aber das configure macht schon ärger das ganze als crosscompile zu bauen.
Ich denke mir so langsam wird es zeit sich von mISDN und chan_lcr zu verabschieden....

peter

 

[pette]

Hallo Peter,

Ich wäre auch dafür, sich von mISDN/chan_lcr zu verabschieden. Allerdings bin ich gerade nicht all zu sehr auf dem Laufenden, was Alternativen angeht.
Hast Du schon ne Idee?

Gruss,
Pette

 

[Michael.de]

Hallo Pette,

die erfolgsversprechende Alternative zu mISDN/chan_lcr wäre wohl vzaphfc/dahdi.

Libpri ab Version 1.4.11 unterstützt den NT-Mode, mehrere TEIs und BRI-phones.
Lediglich DAHDI kommt mit dem NT-Mode noch nicht klar, aber das dürfte sich bald ändern. Einen Patch gibt es schon.

Ich bin mir aber nicht ganz sicher, ob für ISDN die HSS-Sachen der Horstbox gebraucht werden, ich glaube aber eher nicht die sind wohl nur zum Verbinden der analog-Ports untereinander.

Gruß Michael

 

[rmh]

[...] die erfolgsversprechende Alternative zu mISDN/chan_lcr wäre wohl vzaphfc/dahdi.

Sehe ich auch so. Siehe auch Post #302, http://zaphfc.florz.dyndns.org/ und hier: vzaphfc-port für dahdi: http://code.google.com/p/zaphfc/ bzw. als patch hier: http://svn.debian.org/viewsvn/pkg-voip/dahdi-linux/trunk/debian/


EDIT: Hier noch der Auszug zur spandsp / libtiff Fehlermeldung, auch auf meinem Fileserver bricht der build ab. Mal die Frage in die Runde, bei wem läuft der build durch??

Linux evo 2.6.32-5-686 #1 SMP Sun May 30 12:04:26 UTC 2010 i686

[...] .libs/lpc10_encode.o .libs/lpc10_placev.o .libs/lpc10_voicing.o .libs/modem_echo.o .libs/modem_connect_tones.o .libs/noise.o .libs/oki_adpcm.o .libs/playout.o .libs/plc.o .libs/power_meter.o .libs/queue.o .libs/schedule.o .libs/sig_tone.o .libs/silence_gen.o .libs/super_tone_rx.o .libs/super_tone_tx.o .libs/swept_tone.o .libs/t4_rx.o .libs/t4_tx.o .libs/t30.o .libs/t30_api.o .libs/t30_logging.o .libs/t31.o .libs/t35.o .libs/t38_core.o .libs/t38_gateway.o .libs/t38_non_ecm_buffer.o .libs/t38_terminal.o .libs/testcpuid.o .libs/time_scale.o .libs/tone_detect.o .libs/tone_generate.o .libs/v17rx.o .libs/v17tx.o .libs/v18.o .libs/v22bis_rx.o .libs/v22bis_tx.o .libs/v27ter_rx.o .libs/v27ter_tx.o .libs/v29rx.o .libs/v29tx.o .libs/v42.o .libs/v42bis.o .libs/v8.o .libs/vector_float.o .libs/vector_int.o  /usr/lib/libtiff.so -L/usr/lib -lm  -Wl,-soname -Wl,libspandsp.so.2 -o .libs/libspandsp.so.2.0.0
/usr/lib/libtiff.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[2]: *** [libspandsp.la] Fehler 1
make[2]: Leaving directory `/root/r202/spandsp-0.0.6/src'
make[1]: *** [install-recursive] Fehler 1
make[1]: Leaving directory `/root/r202/spandsp-0.0.6'
make: *** [spandsp_install] Fehler 2

evo:~/r202#

 

[pette]

Hallo rmh,

Ich bekomme den "gleichen" Fehler beim Bauen von spandsp wie Du:

armeb-linux-gcc -shared  .libs/adsi.o .libs/async.o .libs/at_interpreter.o .libs/awgn.o .libs/bell_r2_mf.o .libs/bert.o .libs/bit_operations.o .libs/bitstream.o .libs/complex_filters.o .libs/complex_vector_float.o .libs/complex_vector_int.o .libs/crc.o .libs/dds_float.o .libs/dds_int.o .libs/dtmf.o .libs/echo.o .libs/fax.o .libs/fax_modems.o .libs/fsk.o .libs/g711.o .libs/g722.o .libs/g726.o .libs/gsm0610_decode.o .libs/gsm0610_encode.o .libs/gsm0610_long_term.o .libs/gsm0610_lpc.o .libs/gsm0610_preprocess.o .libs/gsm0610_rpe.o .libs/gsm0610_short_term.o .libs/hdlc.o .libs/ima_adpcm.o .libs/logging.o .libs/lpc10_analyse.o .libs/lpc10_decode.o .libs/lpc10_encode.o .libs/lpc10_placev.o .libs/lpc10_voicing.o .libs/modem_echo.o .libs/modem_connect_tones.o .libs/noise.o .libs/oki_adpcm.o .libs/playout.o .libs/plc.o .libs/power_meter.o .libs/queue.o .libs/schedule.o .libs/sig_tone.o .libs/silence_gen.o .libs/super_tone_rx.o .libs/super_tone_tx.o .libs/swept_tone.o .libs/t4_rx.o .libs/t4_tx.o .libs/t30.o .libs/t30_api.o .libs/t30_logging.o .libs/t31.o .libs/t35.o .libs/t38_core.o .libs/t38_gateway.o .libs/t38_non_ecm_buffer.o .libs/t38_terminal.o .libs/testcpuid.o .libs/time_scale.o .libs/tone_detect.o .libs/tone_generate.o .libs/v17rx.o .libs/v17tx.o .libs/v18.o .libs/v22bis_rx.o .libs/v22bis_tx.o .libs/v27ter_rx.o .libs/v27ter_tx.o .libs/v29rx.o .libs/v29tx.o .libs/v42.o .libs/v42bis.o .libs/v8.o .libs/vector_float.o .libs/vector_int.o  /usr/lib/libtiff.so -L/usr/lib -lm  -Wl,-soname -Wl,libspandsp.so.2 -o .libs/libspandsp.so.2.0.0
/usr/lib/libtiff.so: file not recognized: File format not recognized
collect2: ld returned 1 exit status
make[3]: *** [libspandsp.la] Fehler 1

Scheint wirklich so, als ob er die libtiff.so nicht aus dem libdir der toolchain nimmt, sondern vom lokalen System. Hm, merkwürdig.

Gruss,
Pette

 

[rmh]

Um wieder ein lauffähiges System zu bekommen, bin ich nun tatsächlich wieder auf spandsp-0.0.5 zurückgegangen (danke für den Tipp, potc). Ich hatte keine Lust, den diversen Bugs nachzugehen, da ich spandsp derzeit nicht benötige. Mein Faxe werden per fax2mail vom Provider zugestellt. Wenn jemand die Lösung kennt, lasst es uns bitte wissen.
Der build läuft nun wieder durch.

 

[horatio42]

...
die erfolgsversprechende Alternative zu mISDN/chan_lcr wäre wohl vzaphfc/dahdi.
...

Naja, "erfolgversprechend"...
Ich doktere schon ewig daran rum diese Patches auf der aktuellen OpenHorst zum Funktionieren zu überreden, leider bisher ohne Erfolg; siehe auch meine Posts in diesem Thread.

Quintessenz: die Treiber lassen sich bauen, reagieren auch auf Aktivität auf der ISDN-Leitung, aber Asterisk behauptet steif und fest dass die Leitung down sei.

Die Leute die das ganze auf x86 ans Laufen bekommen haben hatten wohl das Problem dass ihre Single-Port-HFC-S-Karten sich nicht ihren Interrupt mit anderer Hardware sharen dürfen. Dummerweise liegen bei Horst beide HFC-S Chips auf dem gleichen Interrupt (24).
Leider kann ich den NT-Mode chip nicht auslöten Ich bräuchte nämlich eh nur TE und NT funzt wohl auch noch so gar nicht mit diesem Treiber (auch auf x86 nicht). (Mal ganz davon abgesehen was die Horst-Entwickler geritten hat statt eines Dual-Port-Chips zwei Single-Port-Chips zu verbauen....) Ich habe versucht den NT-Chip über das sysfs zu disablen, was aber zu sofortiger Kernel-Panic führt wenn man danach den verbliebenen TE-Chip konfigurieren will...

Für mich sieht das nach einem fetten Bug im vzaphfc-Treiber aus (Race-Condition oder falsch bzw. nicht gelockte Ressourcen).

ALLERDINGS, hab ich dann vor einigen Tagen versucht das Ganze - quasi als Gegenprobe - mit mISDN wieder zum Laufen zu bringen, und da kriege ich nun diese Fehlermeldungen im Sekundentakt:

[Jan  1 01:00:37] NOTICE[593]: chan_lcr.c:351 send_message: [call=NULL ast=NULL] Sending MESSAGE_HELLO to socket.
[Jan  1 01:00:37] ERROR[593]: chan_lcr.c:1441 handle_socket: [call=NULL ast=NULL] Socket failed (errno 0).
[Jan  1 01:00:37] ERROR[593]: chan_lcr.c:1652 chan_thread: [call=NULL ast=NULL] Handling of socket failed - closing for some seconds.
[Jan  1 01:00:43] NOTICE[593]: chan_lcr.c:1662 chan_thread: [call=NULL ast=NULL] Retry to open socket.

Ich hatte das schon länger nicht probiert (nicht seit dem move zu asterisk 1.6.2.x). Kann aber natürlich auch sein dass mein Setup ein Problem hat (Verkabelung usw.) und die vzaphfc inzwischen gehen müsste... ich halte das aber für eher unwahrscheinlich da es definitiv auch im direkten Vergleich mit einem gut laufenden mISDN nicht funktionierte... ist nur halt schon was her das ich das getestet habe.

Wenn ich die Zeit dafür finde, werde ich es die Tage nochmal weiter probieren. Sorry, ich wollte Euch nicht entmutigen es ist halt nur recht frustrierendes Gewühle...

Gruss,
H.