Lazarus-Anwendung mit QT weitergeben (libqt4intf.so)

[Giantics]

(um Environment variable LD_LIBRARY_PATH erweitert glaube ich. Damit kann mann lokal die globale ld.so.conf overriden)

Das könnte man zwar tun, allerdings halte ich das nicht für eine gute Lösung. Was passiert, wenn mehrere Lazarus-QT-Anwendungen installiert werden und jede bringt ihre eigene libqt4intf.so mit und erweitert den LIBRARY_PAHT? Dann finden sich in den Pfaden mehrere gleiche Bibliotheken, eventuell mit unterschiedlichen Versionen! Ich denke sowas sollten wir vermeiden und das lieber, wie von Targion vorgeschlagen, als Abhängigkeit in einem eigenen Package realisieren.

[marcov]

Linux ist nicht Windows! LD sucht in den in /etc/ld.so.conf angegebenen Pfaden ...

(um Environment variable LD_LIBRARY_PATH erweitert glaube ich. Damit kann mann lokal die globale ld.so.conf overriden)

Ja, darum dann mein Code Beispiel eines solchen Skriptes.

Das Skript ist dann vielliecht Falsch . Es nimmt an das der User LD_LIBRARY_PATH nicht im .profile gesetzt hat:

#!/bin/sh
basepath=$(pwd)
LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$basepath":$basepath/meineanwendung

Fuer normale Anwender kein Problem, aber Leute auf multiuser Installationen haben oft eine Menge lokale userspecificsche an der Environment.

Das ist nicht ganz zo weit entfernt. Wenn ich zb ports (oder rpm/deb packages) in eine lokale (im Home verzeichnis) Hierarchie installiert habe, habe ich das lib/ Verzeichnis dieser Hierarchie vielleicht in LD_LIBRARY_PATH stehen.

[Hitman]

Stimmt natürlich, das Problem ist dann (soweit ich mich erinnere) aber, dass das in deiner Form schief geht, wenn LD_LIBRARY_PATH noch nicht gesetzt ist. Folglich müsste man das ganze eigentlich in einen if-Block werfen.

Code: Alles auswählen

#!/bin/sh
basepath=$(pwd)
if [ "$LD_LIBRARY_PATH" ]; then
  LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$basepath"
else
  LD_LIBRARY_PATH="$basepath"
fi
export LD_LIBRARY_PATH
$basepath/meineanwendung

Zufrieden?

[Targion]

Da ich ein Paket mit der Bibliothek sowieso für meine Build Service Experimente brauche, habe ich es schon mal veröffentlicht: Am Buildservice-FrontEnd kann man jetzt das Paket als DEB und RPM herunterladen.
Du musst den Nutzern deines Prohrammes nur sagen, dass sie das passende Paket für ihre Distribution vorher installieren müssen, oder aber einfach "libqt4intf" zu den Paketabhängigkeiten in deinem Spec- oder Controlfile hinzufügen.

[Giantics]

So ist das eine saubere Sache!
Habe gerade das deb-Paket für Debian-Etch runtergeladen, ich glaube allerdings im Gegensatz zu den rpm-Paketen fehlt da die libqt4intf.so

[Targion]

Hmm... Liegt vermutlich daran, dass ich mit dem Bauen von DEB-Paketen im build Service noch keine Erfahrung habe. Danke für die Info, ich korrigiere das sofort.

[creed steiger]

Hmm... Liegt vermutlich daran, dass ich mit dem Bauen von DEB-Paketen im build Service noch keine Erfahrung habe. Danke für die Info, ich korrigiere das sofort.

Danke für die Pakete.
Mit LD_LIBRARY_PATH rumspielen ist nicht ganz ungefährlich.
So ist das eine saubere Sache.