ubuntuusers.de

Launchpad - Eigene Bibliotheken als Abhängigkeit

Status: Gelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |

Shakesbier

Avatar von Shakesbier

Anmeldungsdatum:
14. Juli 2008

Beiträge: 1169

Hallo zusammen,

ich habe versucht InyokaEdit etwas zu Modularisieren und habe Teile des Codes in Bibliotheken ausgelagert (libtemplates, libparser). Leider bekomme ich es jetzt nicht mehr hin, das deb Paket auf Launchpad zu bauen, da beim Buildprozess die oben genannten Bibliotheken nicht gefunden werden (dpkg-shlibdeps: error: couldn't find library libtemplates.so.1). Kompletter Log: Buildlog

Prinzipiell ist mir klar, was mir die Fehlermeldung sagen will. Aber ich weiß leider nicht, wie die Debian-Dateien aussehen müssen, damit die Bibliotheken beim Bauen gefunden werden. Bibliotheken + die Anwendung befinden sich in einem Projekt und die Bibliotheken werden auch vor der Hauptanwendung gebaut. Lokal funktioniert es mit den Abhängigkeiten. Kann mir hier jemand weiterhelfen? Quellcode, Debian-Dateien

djcj

Avatar von djcj

Anmeldungsdatum:
28. August 2013

Beiträge: 240

Bibliotheken sollten nach /usr/lib oder /usr/lib/*-linux-gnu, sonst findet Debhelper die nicht.

Ich hab das Rules-Skript mal angepasst:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
#!/usr/bin/make -f
export DH_VERBOSE=1

export DEB_BUILD_HARDENING=1

%:
	dh $@ --parallel

override_dh_auto_install:
	dh_auto_install
	
	# lösche die Links für Dev-Pakete
	rm -f debian/inyokaedit/usr/lib/inyokaedit/*.so
	
	# Libs verschieben
	mv debian/inyokaedit/usr/lib/inyokaedit/* debian/inyokaedit/usr/lib
	mv debian/inyokaedit/usr/share/inyokaedit/plugins/* debian/inyokaedit/usr/lib/inyokaedit
	
	# Leeres Plugin-Verzeichnis entfernen und durch Link ersetzen
	# architekturabhängige Dateien dürfen niemals nach /usr/share
	rm -rf debian/inyokaedit/usr/share/inyokaedit/plugins
	ln -frs debian/inyokaedit/usr/lib/inyokaedit debian/inyokaedit/usr/share/inyokaedit/plugins

Lässt sich problemlos bauen und installieren. Und dann kommt die Fehlermeldung. Musst wohl die Such- und Installationspfade mal ändern.

Bilder

Shakesbier

(Themenstarter)
Avatar von Shakesbier

Anmeldungsdatum:
14. Juli 2008

Beiträge: 1169

Hi djcj,

vielen Dank für Deine Rückmeldung und Deinen Test! Du hast mich genau auf die Fehler gestoßen, die ich selbst übersehen habe ☺ Wie Du richtig schreibst, habe ich die Bibkiotheken an die falsche Stelle installiert (bzw. dem System nicht gesagt, wo die Libs zu finden sein sollen). Nach etwas rumprobieren und weiterer Recherche habe ich jetzt eine andere Lösung gefunden, ohne die rules-Datei anzupassen.

Da ich die Libs und Plugins gerne in /usr/lib/inyokaedit hätte, musste ich diesen Ordner in den .pro Dateien der einzelnen Module hinterlegen (QMAKE_RPATHDIR += /usr/lib/inyokaedit). Nochmals tausend Dank für Deine Antwort, ansonsten wäre ich vermutlich noch länger an dem Problem verzweifelt oder hätte irgendwann aufgegeben. Ein neues Paket befindet sich in Arbeit und wird in Kürze veröffentlicht!

djcj

Avatar von djcj

Anmeldungsdatum:
28. August 2013

Beiträge: 240

RPaths, hmm, das gibt Lintian-Fehlermeldungen (lintian paket.deb). Wenn es ohne RPaths nicht geht solltest du diese Lintian-Tags überscheiben. Ich weiß jetzt nicht wie gut du dich mit Paketerstellung auskennst, aber ich selbst versuche immer möglichst konforme Pakete zu erstellen. Ich würde als RPath übrigens $ORIGIN/../lib/inyokaedit benutzen, dann lässt sich ein selbst kompiliertes Paket auch aus /usr/local heraus starten. Erstellt QMAKE_RPATHDIR eigentlich einen RPath oder RunPath, weil letzteres meines Wissens zu bevorzugen ist (würde mich da aber noch mal zu belesen, gibt da irgendeinen Unterschied zwischen den beiden).

Ach, und für private Libs brauchst du keine LD-Links oder wie sich das nennt zu benutzen. meinebibliothek.so reicht da vollkommen aus. Diese Links sind nur für gemeinsame Bibliotheken wichtig.

Shakesbier

(Themenstarter)
Avatar von Shakesbier

Anmeldungsdatum:
14. Juli 2008

Beiträge: 1169

Hi djcj,

[...] Ich weiß jetzt nicht wie gut du dich mit Paketerstellung auskennst [...]

so gut wie gar nicht 😬. Früher hat sich ein ehemaliger Kollege vom uu-Team um die Paketierung gekümmert. Jetzt hat er leider keine Zeit mehr und ich nutzte mehr oder weniger "Trail and error", um das irgendwie hin zu bekommen.

RPaths, hmm, das gibt Lintian-Fehlermeldungen (lintian paket.deb). Wenn es ohne RPaths nicht geht solltest du diese Lintian-Tags überscheiben. [...] aber ich selbst versuche immer möglichst konforme Pakete zu erstellen.

Ok. Wenn es ohne großen Aufwand machbar ist, konforme Pakete zu erstellen, würde ich das auch bevorzugen. Es geht auch ohne RPaths, dann müsste ich nur meine beiden Bibliotheken nach /usr/lib anstelle nach /usr/lib/inyokaedit installieren (vermute ich). Ich wollte halt alles in "meinem" Unterordner haben, da sehr wahrscheinlich niemand sonst meine Libs braucht. Aber wenn die Installation in den Unterordner Probleme macht, bzw. die Installation direkt in /usr/lib keine Nachteile bringt, kann/werde ich das auch wieder zurück ändern.

Ich würde als RPath übrigens $ORIGIN/../lib/inyokaedit benutzen, dann lässt sich ein selbst kompiliertes Paket auch aus /usr/local heraus starten. Erstellt QMAKE_RPATHDIR eigentlich einen RPath oder RunPath, weil letzteres meines Wissens zu bevorzugen ist (würde mich da aber noch mal zu belesen, gibt da irgendeinen Unterschied zwischen den beiden).

Ach, und für private Libs brauchst du keine LD-Links oder wie sich das nennt zu benutzen. meinebibliothek.so reicht da vollkommen aus. Diese Links sind nur für gemeinsame Bibliotheken wichtig.

Ähm sorry ... zu beiden Absätzen kann ich leider nichts konstruktives beitragen 😳 Wenn Du Zeit und Lust hast, können wir die Paketierung gerne optimieren. Sofern die obige Installation nach /usr/lib schon die Hauptprobleme löst, würde ich das sofort machen.

djcj

Avatar von djcj

Anmeldungsdatum:
28. August 2013

Beiträge: 240

Klar, ich helfe gern. Alternative zum RPath wäre noch den LD-Suchpfad zu überschreiben, also die ausführbare Binärdatei ebenfalls nach /usr/lib/inyokaedit zu installieren und dann das Programm über ein Shellscript zu starten:

1
2
#!/bin/sh
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/inyokaedit /usr/lib/inyokaedit/inyokaedit "$@"

Shakesbier

(Themenstarter)
Avatar von Shakesbier

Anmeldungsdatum:
14. Juli 2008

Beiträge: 1169

Danke djcj! Habe aktuell wenig Zeit, aber ich werde mir die Möglichkeiten durch den Kopf gehen lassen und testen.

djcj

Avatar von djcj

Anmeldungsdatum:
28. August 2013

Beiträge: 240

Habe mich nochmal dran gesetzt und ein Paket aus dem aktuellen Quelltext (03.07.2014) erstellt:

Für Änderungen am Originalcode siehe patches-Ordner. Außerdem habe ich den Hardening-Kram aus debian/rules entfernt, weil die Binärdatei dadurch falsch gelinkt wurde.

Shakesbier

(Themenstarter)
Avatar von Shakesbier

Anmeldungsdatum:
14. Juli 2008

Beiträge: 1169

Wow danke! Wird ein paar Tage dauern, aber sieht auf den ersten Blick sehr vielversprechend aus!

djcj

Avatar von djcj

Anmeldungsdatum:
28. August 2013

Beiträge: 240

Ich hab mal ein paar Veränderungen an den .pro-Dateien vorgenommen, so dass fast alles über qmake installiert werden kann:

Ich hab auch versucht die hardcoded Pfade (/usr/lib/inyokaedit) im C++ Quelltext durch relative Pfade zu ersetzen, jedoch ohne Erfolg. Ich denke das sollte auf jeden Fall gemacht werden, damit das Programm auch in andere Prefixe installiert werden kann.

Habe alle Suchpfade in relative Pfade geändert. Jetzt kann man das Programm auch benutzen, ohne es ins System zu installieren.

Antworten |