vdr-plugin-targavfd

Nicht vergessen das zur Laufzeit auch das Paket libusb-1.0-0 installiert ist, welches die gleiche Version zur libusb-1.0-0-dev hat ...

lokal sieht es so aus, im buildlog werden die gleichen versionen gezogen:

ii libusb-1.0-0 2:1.0.9~rc3-2ubuntu1 userspace USB programming library
ii libusb-1.0-0-dev 2:1.0.9~rc3-2ubuntu1 userspace USB programming library development files

die 0.1.1 läuft ja hier ... ?

Hier schonmal das buildlog von Launchpad/PPA:

https://launchpadlibrarian.net/136758416/buildlog_ubuntu-precise-amd64.vdr-plugin-targavfd_0.2.0-1yavdr0~precise_UPLOADING.txt.gz

Mir fällt da nix auf, das von von dort installierte binäre Paket funktioniert ja direkt nicht, daher danach die lokalen Tests, mit gleichem Ergebnis.

Die anderen lokalen Infos reiche ich heute Abend nach.

Hatte doch noch ein paar Minuten:

vdr2-vdr:/home/vdr> dpkg --get-selections |grep libusb
libusb-0.1-4 install <= Ist eine Abhängigkeit von mehreren Paketen
libusb-1.0-0 install
libusb-1.0-0-dev install

vdr2-vdr:/home/vdr> pkg-config --cflags libusb-1.0
-I/usr/include/libusb-1.0

vdr2-vdr:/home/vdr> pkg-config --libs libusb-1.0
-lusb-1.0

vdr2-vdr:/home/vdr> cat /usr/include/libusb-1.0/libusb.h | grep libusb_close
* later destroyed by libusb_close().
* with a device handle, you should call libusb_close().
void LIBUSB_CALL libusb_close(libusb_device_handle *dev_handle);

vdr2-vdr:/home/vdr> dpkg -L libusb-1.0-0-dev | grep libusb-1.0.a
/usr/lib/x86_64-linux-gnu/libusb-1.0.a

vdr2-vdr:/home/vdr> strings /usr/lib/x86_64-linux-gnu/libusb-1.0.a | grep libusb_close
libusb_close
libusb_close
libusb_close

Einen lokalen Buildlog reiche ich nach, aber der sah IIRC nicht anders aus als der von Launchpad ...

Gemäß deinen lokalen Ausgaben ist doch libusb_close in der Bibliothek /usr/lib/x86_64-linux-gnu/libusb-1.0.a vorhanden ...

Ich kann auch keine Fehlermeldungen beim Kompilieren des Plugins sehen.

Beim Erstellen sind mir folgende Sachen in Auge gestoßen

make¹: Leaving directory `/build/buildd/vdr-plugin-targavfd-0.2.0'
dh_makeshlibs -a
dh_shlibdeps -a
dh_installdeb -a
dh_gencontrol -a
dpkg-gencontrol: warning: Depends field of package vdr-plugin-targavfd: unknown substitution variable ${vdr:Depends}
dh_md5sums -a
dh_builddeb -a

...

vdr-plugin-span würde ich eher als "Suggest" betrachten, das Plugin targavfd ist nicht davon abhängig (die Bindung erfolgt zur Laufzeit per Service Interface)
aber als Depends fehlt libusb >= 1.0

Maintainer: Debian VDR Team <pkg-vdr-dvb-devel@lists.alioth.debian.org>
 Installed-Size: 158
Depends: libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.1.1), vdr-plugin-span
 Section: video

Übrigens die Projekthomepage stimmt nicht :

Priority: extra
Homepage: http://projects.vdr-developer.org/wiki/plg-imonlcd
 Description: VDR plugin to show information on Targa VFD Futaba MDM166A

BTW: Eventuell mit ldd prüfen welche Datei für libusb-1.0.so.0 verwendet wird.

# ldd libvdr-targavfd.so.2.0.0
    linux-gate.so.1 =>  (0xb7795000)
    libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xb76cb000)
    libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb76b2000)
    libusb-1.0.so.0 => /lib/i386-linux-gnu/libusb-1.0.so.0 (0xb76a0000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb75b4000)
    libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb758e000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7571000)
    libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb740e000)
    librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb7404000)
    libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb73eb000)
    /lib/ld-linux.so.2 (0xb7796000)

Denn einzigen Unterschied, den ich momentan sehe ist dein Einsatz in einer 64bit Umgebung, ich kann mir aber nicht vorstellen das dies die Ursache ist. Ich tippe eher auf ein Fehler beim Erstellen des Paketes.

Ja, stehe ja ebenso ratlos da. Aber ich werde die vdr-plugin-span zum "suggest" definieren, die Projekthomepage anpassen, libusb (>= 1.0) definieren, alles andere nomm'l auf den Prüfstand stellen und es dann neu bauen lassen.

Lt. Buildlog wurde aber libusb-1.0 für den make angezogen, kann also fast kein Problem sein. 64-bit wäre auch überraschend, die Vorgängerversion läuft ja hier mit 64-bit, eben seit mir die Buben im Portal das MDM166A empfohlen haben. Aber Launchpad/PPA baut ja beides, 32- und 64-bit ...

Nun, denn melde mich später nomm'l

[OT] Was ist die Beste Schriftart für 2-zeilige Anzeige? Ohne Serifen ...[/OT]

Hab eben mal kurz das 0.2.0-deb ausgepackt und das binary rausgeholt:

ldd libvdr-targavfd.so.2.0.0
        linux-vdso.so.1 =>  (0x00007ffff19ac000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f117c918000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f117c702000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f117c342000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f117c046000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f117ce3f000)

ldd /usr/lib/vdr/plugins/libvdr-targavfd.so.2.0.0
        linux-vdso.so.1 =>  (0x00007fff17dff000)
        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f6acb684000)
        libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f6acb475000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6acb174000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6acaf5e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6acab9f000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6aca987000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6aca77f000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6aca562000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6aca265000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6acbb48000)

So wie es aus sieht fehlt libusb beim linken.

Was mich wundert, laut deinem Log ist -lusb-1.0 enthalten.

g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE *-Wl,-Bsymbolic-functions -Wl,-z,relro* -L/usr/lib/x86_64-linux-gnu -lfreetype -lz -lusb-1.0   -shared targavfd.o bitmap.o vfd.o ffont.o setup.o status.o watch.o span.o -o libvdr-targavfd.so

Probiere mal diese Veränderung im Makefile, bei der Umstellung auf VDR>=1.7.36 scheint sich eine andere Reihenfolge eingeschlichen zu haben. Bringe mal das $(LIBS) Statement im Makefile an den alten Platz aus Version 0.1.1.

diff --git a/Makefile b/Makefile
index 12f4b17..fa9c75b 100644
--- a/Makefile
+++ b/Makefile
@@ -113,7 +113,7 @@ install-i18n: $(I18Nmsgs)
 ### Targets:

 $(SOFILE): $(OBJS)
-       $(CXX) $(CXXFLAGS) $(LDFLAGS) $(LIBS) -shared $(OBJS) -o $@
+       $(CXX) $(CXXFLAGS) $(LDFLAGS) -shared $(OBJS) $(LIBS) -o $@

 install-lib: $(SOFILE)
        install -D $^ $(LIBDIR)/$^.$(APIVERSION)

Ja stimmt, da war was, hat einer letztens mal was erwähnt, wegen der Reihenfolge, teste es eben mal.

Aber erstmal zu den restlichen Empfehlungen, bei Ubuntu gibt es nur "libusb-1.0-0" & "libusb-1.0-0-dev", letzteres ist als Build-Abhängigkeit definiert, woraus debhelper automatisch dem binären Paket die Abhängigkeit "libusb-1.0-0" zuweist, da muß ich (eigentlich) nichts machen.

dpkg-gencontrol ist nur ein Warning, wir nutzen eine geänderte "rules", die diese Substituierung nimmer füllt, kein Aufruf von dependencies.sh mehr. Müssen wir mal klären wie bereinigen, ob überhaupt ... könnte das einfach rausnehmen ...

Homepage ist korrigiert.

Was bedeutet:

watch.c: In Elementfunktion »void cVFDWatch::Recording(const cDevice*, const char*, const char*, bool)«:
watch.c:686:5: Warnung: Format »%d« erwartet Argumenttyp »int«, aber Argument 3 hat Typ »long unsigned int« [-Wformat]

Die Änderung im Makefile hat's gebracht:

ldd libvdr-targavfd.so.2.0.0
        linux-vdso.so.1 =>  (0x00007fff785ff000)
        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f071adbe000)
        libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f071abaf000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f071a8ae000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f071a698000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f071a2d9000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f071a0c1000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0719eb9000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0719c9c000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f071999f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f071b281000)

Btw. "${vdr:Depends}" aus control genommen, Warning weg ... ;-)

[OT] Was ist die Beste Schriftart für 2-zeilige Anzeige? Ohne Serifen ...[/OT]

Ach ja, funktioniert natürlich auch das Plugin, :-) , mal sehen was sich sonst geändert hat.

Zu den Abhängigkeiten nochmal:

Hängt ab von: libc6 (>= 2.14), libfreetype6 (>= 2.2.1), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.1.1), libusb-1.0-0 (>=
               2:1.0.9~rc3)

Fein, das dies gelöst. Sorry für die Unannehmlichkeiten ;-)

Ja, sehr fein und nein, keine Unannehmlichkeiten, ich bitte Dich ... 8-)

Da das Paket ja nicht nutzbar war, habe ich es mit dem Patch in die PPAs gequetscht, jetzt kannst Du gucken ob für eine 0.2.1 noch was zu tun wäre, ich schiebs dann nach :-)

Ja, "Bitstream Vera Sans:Roman" ist mein Wahl aktuell, gut lesbar für mich in 2-3m, ... noch ... ^^

Den PT werde ich mal testen.

Hab Dank für Deine Mühen.