• Dieses Thema ist leer.
Ansicht von 15 Beiträgen - 1 bis 15 (von insgesamt 16)
  • Autor
    Beiträge
  • #16081
    arnoburger
    Teilnehmer

    Hallo Thilo,

    da ich im Moment keine graphische Oberfläche habe, versuche ich gerade mal die Console-Version https://downloads.janrufmonitor.de/released/5.0/jam50-console-capi.zip auszuprobieren.
    Betriebssystem: openSUSE 11.4 64bit, Kernel 3.1.0
    ISDN-Gerät: Gigaset SX255 mit CAPI-Treiber
    Nach dem Entpacken des ZIP-Archivs habe ich (wie gerade nebenan von Dir empfohlen) 64bit/libpimcapi.so nach ./libpimcapi.so verschoben.

    Wenn ich jetzt ./jam.sh aufrufe, startet jAnrufmonitor, beendet sich aber sofort wieder:


    ts@xenon:~/Downloads/jam50-console-capi> ./jam.sh
    Welcome to jAnrufmonitor 5 Console:
    ===================================

    Starting jAnrufmonitor ...
    Configuration must be done in janrufmonitor.properties.

    Help - HELP +
    Status - STATUS +

    Journal - JOURNAL +

    Search updates - SEARCHUPDATES +

    Module update - UPDATE +
    Module installation - INSTALL +
    Import callers - IMPORT +

    Call Simulation - SIMULATE +
    Info - INFO +

    Re-start - RESTART +

    Quit - QUIT +


    JAM>java: symbol lookup error: /usr/lib64/capi/lib_capi_mod_std.so: undefined symbol: processMessage
    ts@xenon:~/Downloads/jam50-console-capi>

    Der Dateiname und das undefinierte Symbol sind nicht immer gleich, ich hatte auch schon
    „/usr/lib64/capi/lib_capi_mod_fritzbox.so: undefined symbol: getHostName“

    In logs/jam-0.log tauchen einige Warnungen auf, deren Schweregrad ich nicht beurteilen kann:


    [ WARNING - 03/Nov/2011:17:47:30 +0100 - main - de.janrufmonitor.framework.command.CommandFactory.startup() - Could not find class: de.janrufmonitor.service.trayicon.Activator ]
    [ WARNING - 03/Nov/2011:17:47:30 +0100 - main - de.janrufmonitor.framework.command.CommandFactory.startup() - Could not find class: de.janrufmonitor.ui.jface.application.donation.DonationCommand ]
    [ WARNING - 03/Nov/2011:17:47:30 +0100 - main - de.janrufmonitor.framework.command.CommandFactory.startup() - Could not find class: de.janrufmonitor.ui.jface.application.update.UpdatesCommand ]
    [ WARNING - 03/Nov/2011:17:47:30 +0100 - main - de.janrufmonitor.framework.command.CommandFactory.startup() - Could not find class: de.janrufmonitor.ui.jface.dialogs.DialogPropagator ]
    [ WARNING - 03/Nov/2011:17:47:30 +0100 - main - de.janrufmonitor.framework.command.CommandFactory.startup() - Could not find class: de.janrufmonitor.ui.jface.configuration.ConfigurationCommand ]
    [ WARNING - 03/Nov/2011:17:47:30 +0100 - main - de.janrufmonitor.framework.command.CommandFactory.startup() - Could not find class: de.janrufmonitor.ui.jface.application.journal.JournalCommand ]
    [ WARNING - 03/Nov/2011:17:47:30 +0100 - main - de.janrufmonitor.framework.command.CommandFactory.startup() - Could not find class: de.janrufmonitor.ui.swt.controls.ConfigShutdown ]
    [ WARNING - 03/Nov/2011:17:47:30 +0100 - main - de.janrufmonitor.framework.command.CommandFactory.startup() - Could not find class: de.janrufmonitor.ui.jface.application.editor.EditorCommand ]
    [ WARNING - 03/Nov/2011:17:47:30 +0100 - main - de.janrufmonitor.framework.command.CommandFactory.startup() - Could not find class: de.janrufmonitor.ui.jface.application.info.InfoCommand ]
    [ WARNING - 03/Nov/2011:17:47:30 +0100 - main - de.janrufmonitor.framework.command.CommandFactory.startup() - Could not find class: de.janrufmonitor.ui.jface.application.help.WebHelpCommand ]
    [ WARNING - 03/Nov/2011:17:47:30 +0100 - main - de.janrufmonitor.framework.command.CommandFactory.startup() - Could not find class: de.janrufmonitor.ui.jface.application.last10calls.Last10CallsCommand ]
    [ WARNING - 03/Nov/2011:17:47:31 +0100 - main - de.janrufmonitor.service.ServiceFactory.startup() - Could not find class: de.janrufmonitor.service.config.ConfigService ]
    [ WARNING - 03/Nov/2011:17:47:31 +0100 - main - de.janrufmonitor.service.ServiceFactory.startup() - Could not find class: de.janrufmonitor.service.dialog.DefaultCallDialogService ]
    [ WARNING - 03/Nov/2011:17:47:31 +0100 - main - de.janrufmonitor.service.ServiceFactory.startup() - Could not find class: de.janrufmonitor.service.trayicon.TrayIcon ]

    Im Syslog sehe ich


    [77524.563083] bas_gigaset 6-2:1.0: application 1 registered
    [77524.589138] bas_gigaset 6-2:1.0: application 1 released

    d.h. jAnrufmonitor schafft es immerhin, sich als CAPI-Anwendung anzumelden, bevor er 26 ms später abschmiert.

    Was mache ich falsch?

    Danke,
    Tilman

    #24376
    Thilo Brandt
    Keymaster

    Hallo Tilman,

    undefined Symbol Meldungen deuten daraufhin, dass die verwendete CAPI Implementieren nicht alle Methoden der Standard-CAPI beinhaltet. So muss die Methode processMessage in der CAPI vorhanden sein, was bei der erste CAPI nicht der Fall ist. Bei der FritzBox CAPI fehlt anscheinend die getHostName Methode.

    JAM kann nur mit CAPI’s kommunizieren, die den CAPI 2.0 Standard unterstützen.

    Viele Grüße
    Thilo

    #24377
    arnoburger
    Teilnehmer

    Hallo Thilo,

    die Frage, die sich mir da stellt, ist warum jAnrufmonitor mit all diesen CAPIs kommunizieren will.
    Warum nimmt es nicht einfach die CAPI für den einzigen ISDN-Adapter, den ich tatsächlich angeschlossen habe – die Gigaset? Deren Treiber habe ich höchstpersönlich programmiert und bin deshalb verhältnismäßig sicher, dass er CAPI 2.0 unterstützt. Eine Fritzbox habe ich überhaupt nicht, also sollte es doch egal sein, ob dem Fritzbox-Treiber irgendwelche Methoden fehlen. Oder sehe ich das falsch?

    Danke,
    Tilman

    #24378
    Thilo Brandt
    Keymaster

    Hallo Tilman,

    jAnrufmonitor nimmt alle im System registrierte CAPI Treiber und läd diese. Er kann ja vor dem Laden nicht wissen, welche Hardware tatsächlich angeschlossen ist.

    Grundsätzlich musst du alle Methoden der CAPI 2.0 Spezifikation wie von capo.org definiert implementieren und im Interface exponieren. Dann wird deine CAPI auch vom JAM erkannt.
    http://www.capi.org/download/capi20.zip

    Hast du evt. einzelne Methoden nicht implementiert?

    Noch etwas: Ist deine SO-Datei im LD_LIBRARY_PATH enthalten? Evt. findet die Java Umgebung auch die ganze Bibliothek nicht.

    Viele Grüße
    Thilo

    #24379
    arnoburger
    Teilnehmer

    Hallo Thilo,

    vielen Dank für Deine Antwort. Ein paar Puzzleteile fehlen mir allerdings noch zum Verständnis.
    Was meinst Du mit „nimmt alle im System registrierte CAPI Treiber und läd diese“ und was mit „deine SO-Datei“?

    Laut CAPI-Spezifikation gibt es doch in einem System nur eine CAPI. Bei Windows ist diese als DLL realisiert. (CAPI2032.DLL) Da muss man dann immer die zur eigenen Hardware passende installieren. Deshalb kann man auch nicht mehrere CAPI-fähige Geräte verschiedener Hersteller parallel betreiben.

    Bei Linux ist die CAPI durch die Gerätedatei /dev/capi20 realisiert, und dahinter sitzt der KernelCAPI-Dispatcher, der die Anfragen an mehrere KernelCAPI-Treiber verteilen kann. Einer davon ist der von mir geschriebene Treiber gigaset.ko. Aber den kann und muss nicht die Anwendung laden, das passiert automatisch, wenn das USB-Subsystem eine angeschlossene Gigaset-Basis erkennt.

    Die Methoden processMessage und getHostName tauchen in der CAPI-Spezifikation nicht auf – ich habe extra gerade nochmal nachgeschaut. CAPI-Messages werden per putMessage und getMessage ausgetauscht, und getHostName passt überhaupt nicht ins Bild – das gehört eher in den Bereich Netzwerk und ergäbe für mich höchstens bei einer LAN-CAPI Sinn.

    Also: JAM sollte einfach /dev/capi20 öffnen, per CAPI_GET_PROFILE erfahren, wieviele Controller da sind, sich einen davon aussuchen, per CAPI_PUT_MESSAGE ein LISTEN_REQ darauf absetzen und per CAPI_GET_MESSAGE die eingehenden CONNECT_INDs in Empfang nehmen. Auf meinem früheren 32-bit-System hat das auch genau so funktioniert. Nur jetzt mit 64 bit auf einmal nicht mehr.

    Wo ist mein Denkfehler?

    Danke,
    Tilman

    #24380
    Thilo Brandt
    Keymaster

    Hallo Tilman,

    schau dir am besten mal die CAPI Implementierung direkt in GitHub an: https://github.com/tbrandt77/janrufmonitor/tree/master/modules/capi/c++/linux

    Ich denke, dann wird klarer, wie das ganze funktioniert.

    Viele Grüße
    Thilo

    #24381
    arnoburger
    Teilnehmer

    Hallo Thilo,

    ich hab mir den Code mal durchgelesen.

    Wenn ich das richtig interpretiere, lädt jAnrufmonitor gar nicht selbst irgendwelche Treiber, sondern ruft via libpimcapi.so schlicht die Methoden der Standardbibliothek libcapi20.so auf. Die sollte dann ihrerseits einfach die diversen CAPI-Methoden aus den Funktionsaufrufen gem. Kap. 8.16 des CAPI 2.0 Standards in die entsprechenden Zugriffe auf /dev/capi20 umsetzen. Das scheint auch soweit zu funktionieren, denn ich sehe ja im Syslog das capi20_register bei meinem Treiber ankommen.

    Wie es dann dazu kommt, dass noch weitere Shared Libraries aus /usr/lib64/capi geladen werden, die dann mit undefined symbols auf die Nase fallen und JAM mit in den Abgrund reißen, verstehe ich allerdings immer noch nicht. Weder libpimcapi.so noch libcapi20.so ziehen die laut „ldd“ an, also werden die wohl dynamisch geladen – aber von wem und vor allem warum?
    lib_capi_mod_std.so würde ich ja noch hinnehmen (_std klingt so nach Standard), aber lib_capi_mod_fritzbox.so dürfte doch keine Rolle spielen, wenn ich überhaupt keine Fritzbox habe. Wieso dann nicht gleich auch noch lib_capi_mod_rcapi.so, dann hätten wir die Sammlung komplett??

    Was mir auch auffällt, ist dass die so-Dateien in /usr/lib64/capi alle also keine Symboltabellen haben. Kann eine gestrippte Shared Library denn überhaupt funktionieren? So kann ich jedenfalls nicht nachvollziehen, ob die Methoden getHostName und processMessage von dort angefordert werden. Im Code von jAnrufmonitor scheinen die jedenfalls nicht vorzukommen und im CAPI-Standard wie gesagt auch nicht.

    Ich habe auch noch ein bisschen gegoogelt. Kann es sein, dass mein Problem mit diesen hier zusammenhängt?

    viewtopic.php?f=24&t=329
    http://www.foehr-it.de/hlp/viewtopic.php?t=253
    https://bugzilla.novell.com/show_bug.cgi?id=475808

    Danke,
    Tilman

    #24382
    arnoburger
    Teilnehmer

    Ich habe jetzt mal das zuständige openSUSE Source RPM i4l-base-2010.11.8-2.4.src.rpm heruntergeladen und neu gebaut, um zu sehen, warum die so-Dateien gestrippt werden. Wurden sie aber gar nicht! Weiß der Kuckuck, was Suse da beim Bauen des Distributionspakets angestellt hat.

    Daraufhin habe ich mir jetzt die neugebauten, ungestrippten so-Dateien installiert. An der Fehlermeldung hat das zwar nichts geändert. (Schade, wäre doch zu schön gewesen!) Aber ich kann jetzt mit
    nm -u /usr/lib64/capi/lib_capi_mod_*.so
    in der Tat bei allen drei _mod_-Libs ein
    U processMessage
    sowie bei lib_capi_mod_fritzbox.so und lib_capi_mod_rcapi.so auch ein
    U getHostName
    sehen. In
    nm /usr/lib64/libcapi20.so
    sehe ich aber auch
    00000000000036e0 T getHostName
    0000000000004250 T processMessage
    d.h. dort sind diese Symbole definiert. Fragt sich jetzt natürlich, warum sie dann nicht auch dort gefunden werden.

    Als nächstes werde ich mir mal die Quellen in dem Source-RPM näher anschauen. Vielleicht kriege ich ja raus, was da verbockt worden ist. Wenn jemand einen Tipp hat, wonach ich Ausschau halten sollte – immer her damit. 😉

    #24383
    arnoburger
    Teilnehmer

    Hallo Thilo,

    ich habe das Problem gelöst. Es war in der Tat der openSUSE-Bug
    https://bugzilla.novell.com/show_bug.cgi?id=475808
    Mit Unterstützung von
    http://forums.opensuse.org/english/other-forums/development/programming-scripting/
    habe ich jetzt einen Patch entwickelt, der (zumindest auf meinem System) das Problem behebt.
    Den Patch habe ich an den Bugzilla-Eintrag geschickt und hänge ihn auch hier an.
    Ich hoffe, dass die openSUSE-Maintainer ihn bald übernehmen.
    Bis dahin muss man ihn halt selbst anwenden, also:
    – Source RPM installieren
    – Patch ins SOURCE-Verzeichnis kopieren
    – Spec-Datei ergänzen (Patch eintragen, Release-Nummer erhöhen)
    – RPM neu bauen
    – System mit neu gebautem Paket capi4linux aktualisieren

    Viele Grüße,
    Tilman

    #24384
    arnoburger
    Teilnehmer

    Hmm, das mit dem Hochladen des Patches scheint nicht zu klappen – zumindest sehe ich den Dateianhang nirgends. Deshalb hier nochmal als Codeschnipsel:


    Index: isdn4k-utils/capi20/Makefile.am
    ===================================================================
    --- isdn4k-utils.orig/capi20/Makefile.am
    +++ isdn4k-utils/capi20/Makefile.am
    @@ -19,14 +19,17 @@
    lib_capi_mod_std_la_SOURCES = capi_mod_std.c
    lib_capi_mod_std_la_CFLAGS = -fno-strict-aliasing
    lib_capi_mod_std_la_LDFLAGS = -shared
    +lib_capi_mod_std_la_LIBADD = libcapi20.la

    lib_capi_mod_fritzbox_la_SOURCES = capi_mod_fritzbox.c
    lib_capi_mod_fritzbox_la_CFLAGS = -fno-strict-aliasing
    lib_capi_mod_fritzbox_la_LDFLAGS = -shared
    +lib_capi_mod_fritzbox_la_LIBADD = libcapi20.la

    lib_capi_mod_rcapi_la_SOURCES = capi_mod_rcapi.c
    lib_capi_mod_rcapi_la_CFLAGS = -fno-strict-aliasing
    lib_capi_mod_rcapi_la_LDFLAGS = -shared
    +lib_capi_mod_rcapi_la_LIBADD = libcapi20.la

    libcapi20dyn_a_SOURCES = capidyn.c
    libcapi20dyn_a_CFLAGS = -fPIC

    Bitte vor dem Anwenden des Patches am Anfang jeder Zeile, die mit „lib“ beginnt, ein Leerzeichen einfügen – dummerweise hat die Forumssoftware die führenden Leerzeichen entfernt, und ohne die funktioniert es nicht.

    HTH
    Tilman

    #24385
    MIB2
    Teilnehmer

    Ein deja-vu …. ein gar schröööckliches deja-vu

    Schaust Du HIER wie man das umgeht, solange sich CAPI-Entwickler gegenseitig den Schwarzen Peter zuschieben. 😆

    Ich hatte das Problem heute, nach einem FACTORY-Update, nämlich auch, aber nun läuft alles wieder.

    Gruß,

    Michael.

    #24386
    arnoburger
    Teilnehmer

    @Bitmitch wrote:

    Ein deja-vu …. ein gar schröööckliches deja-vu

    😆

    @Bitmitch wrote:

    Schaust Du HIER wie man das umgeht, solange sich CAPI-Entwickler gegenseitig den Schwarzen Peter zuschieben.

    Den Thread hatte ich mir durchaus zu Gemüte geführt. Aus den folgenden Gründen habe ich es dann aber doch vorgezogen, das Problem mal eben sauber zu lösen:
    1. ist die dort genannte Version des capi4linux-Pakets nicht mehr so ohne weiteres aufzutreiben,
    2. ist sie schon so alt, dass mir nicht wohl dabei war, sie in eine aktuelle SuSE einzupflanzen,
    3. gehöre ich noch zu der alten Schule der Open-Source-Anwender, die bei Bedarf auch mal selbst Hand an den Quellcode legen, anstatt nur zu jammern, wie schlecht der Support der (unbezahlten) Entwickler sei,
    4. sah das Problem nicht sooo schwierig aus (und war es dann ja auch nicht), und
    5. will ich es den openSUSE-Benutzern meines Treibers nicht zumuten, auf Dauer mit einer Frickelslösung zu leben.

    Jetzt bin ich mal gespannt, wie lange es dauert, bis mein Patch den Weg in die openSUSE-Mainline findet. Die Enterprise-Leute haben sich offenbar schon bedient …

    #24387
    MIB2
    Teilnehmer

    @tilman:
    Don’t worry. 😀

    Das Problem wurde schon seit 2009 gemeldet, und irgendwann hat mal jemand aus der CAPI/ISDN Truppe sinngemäß geschrieben, dass ihn das nicht mehr interessiere, da er keine ISDN-Karte mehr habe. 😈

    So what, der Trick mit den überschriebenen .so-Files funktioniert seit diversen Versionen einwandfrei, schöner und richtiger ist es natürlich, wenn man den ISDN-Code patched, und dann ein Versionsupdate verteilt, damit hast Du vollkommen recht.

    Nur gehe ich da den pragmatischen Weg, wenn ich nach einem FACTORY das bekannte Problem habe, wende ich die alten .so Files an, solange er denn funktioniert.
    Wenn nicht … na ja, dann muss ich mir abends viel Zeit nehmen, und die habe ich nicht mehr.

    Trotzdem, gut dass Du den Patch gemeldet hast, lassen wir uns also überraschen .. ist ja bald Weihnachten 😆

    Michael.

    #24388
    MIB2
    Teilnehmer

    Mahlzeit an die Community.

    Und wieder einmal ein deja-vu:
    Kaum hat man openSuSE/Balsam 12.1 auf der Maschine laufen, dann mit viel Mühe und Handarbeit und Flickerei endlich die ISDN-Karte in Betrieb, erhält man als Ergebniss seiner Bemühungen die allseits beliebte und bekannte Fehlermeldung:

    the-server:/usr/local/jam # java: symbol lookup error: /usr/lib/capi/lib_capi_mod_std.so: undefined symbol: processMessage

    ICH WERD NARRISCH!!!

    Nach den Diskussionen und dem Patch von @tilman sollten die RPM-Kistenpacker doch wirklich mal darüber nachdenken, ein lauffähiges CAPI mit einzupacken …denn:
    Es IST schon wieder (bald) Weihnachten !!

    Der von mir gerne angewandte Trick des patchens mittels der uralten .so-Files klappt natürlich NICHT mehr, neuer Kernel, neues Glück..

    Ein leicht zerknirschter

    Michael.

    ICH WERD N O C H Narrischer:
    der Trick mit dem Austausch von
    libcapi20.so.2.0.10 und
    libcapi20.so.3.0.4

    klappt IMMER NOCH!!!
    Bei ersten Versuch sind die nur im falschen Verzeichnis gelandet .. ich Depp 😆

    #24389
    arnoburger
    Teilnehmer

    @Bitmitch wrote:

    Kaum hat man openSuSE/Balsam 12.1 auf der Maschine laufen, dann mit viel Mühe und Handarbeit und Flickerei endlich die ISDN-Karte in Betrieb, erhält man als Ergebniss seiner Bemühungen die allseits beliebte und bekannte Fehlermeldung:

    the-server:/usr/local/jam # java: symbol lookup error: /usr/lib/capi/lib_capi_mod_std.so: undefined symbol: processMessage

    Yepp, siehe https://bugzilla.novell.com/show_bug.cgi?id=475808#c19 .

    @Bitmitch wrote:

    Der von mir gerne angewandte Trick des patchens mittels der uralten .so-Files klappt natürlich NICHT mehr, neuer Kernel, neues Glück..

    Mit dem Kernel hat das ganze garnüscht zu tun. Reines Userspace-Problem, genauer: reines openSUSE-Userspace-Problem. Die Standard-libcapi20 der anderen Distributionen hat das Problem nämlich nicht.

    Aber das openSUSE-ISDN-Team hat halt kurz vor seiner Verflüchtigung dieses tolle neue Feature in die libcapi20 eingebaut, dass CAPI-Programme statt mit der lokalen Kernel-CAPI wahlweise auch mit einer Fritzbox oder einer LANCAPI reden können.

    Ist ja auch schön.

    Nur leider waren kurz darauf keine Leute mehr da, um die unvermeidlichen Bugs zu beheben.
    Und das ist dann nicht so schön.

    „Have a lot of fun!“ 😉
    Tilman

Ansicht von 15 Beiträgen - 1 bis 15 (von insgesamt 16)
  • Du musst angemeldet sein, um auf dieses Thema antworten zu können.