Sinn von rpath
-
Hallo!
Beim Erzeugen eines Executables mit g++ kann ich ja einen rpath setzen, z.B.: -Wl,rpath,/home/foo/myLib
D.h. der Loader sucht dann beim Laden von .so unter /home/foo/myLibMeine Frage:
Wenn ich jetzt dieses Executable auf einen anderen Rechner kopiere, dann muessen doch die .so unter /home/foo/myLib liegen. Wie soll ich das aber sicherstellen? Ich verstene nicht so ganz den Sinn von rpath - damit verhindert man doch, dass das Executable auf einem anderen Rechner laeuft?
-
Wenn man mit so einem Pfad kompiliert, dann geht es ja nicht darum, dass man ein portables Executable erstellt. Dann kompiliert man auf dem anderen Rechner eben neu. Aber -rpath fügt glaube ich nur Pfade hinzu. Der runtime Linker schaut danach noch in die üblichen Pfade.
-
KDE?
-
Das Posting über mir ist nicht von mir -.-
Das Problem ist folgendes: Mein erzeugtes Executable hängt von einer selber erstellten foo.so ab, die bei mir unter /home/Projects/FooLib liegt. Beim Erstellen der Executable linke ich nun gegen foo.so und der rpath zeigt auf /home/Projects/FooLib (CMake macht das automatisch).
Auf meinem PC klappt also alles wunderbar. Aber wenn ich das Executable auf einen anderen Rechner kopiere, hat der natürlich NICHT unter /home/Projects/FooLib eine foo.so liegen.
Wie ist da die Standardlösung unter Linux? Die foo.so mitliefern? Auf was setze ich dann den rpath? Den muss ich ja bereits beim Bauen des Executables angeben, aber zu dem Zeitpunkt weiß ich ja nicht, wo der Endnutzer das Programm installieren will!
-
Du setzt gar keinen rpath. Der Nutzer soll seine Bibliotheken dorthin installieren, wo der Runtime-Linker sie auch finden kann. Und falls sie nicht dort liegen, dann compiliert er das Programm neu mit einem passenden rpath, so wie du das auch bei dir selber machst (da die Bibliothek bei dir nicht in einem Pfad liegt, der von deinem Linker durchsucht wird).
-
Naja, dieses CMake setzt automatisch den rpath. Wird dann ja schon einen Sinn haben?
Und was heißt "Der Nutzer soll seine Bibliotheken dorthin installieren". Ich kann dem (oft unerfahrenen) Nutzer ja wohl kaum die foo.so und alles andere schicken und dann erwarten, dass der Nutzer dass nach /usr/local/lib64 etc kopiert. Zumal ich das gar nicht will - die foo.so braucht ja nur das eine Executable.
Ich habe auf mehreren Seiten gelesen, dass man NICHT den LD_LIBRARY_PATH setzen soll, sondern rpath bevorzugen soll. Ich raff nur nicht, wie das mit dem rpath gehen soll, wenn das Programm auf anderen Rechnern laufen soll. Beim Nutzer kompilieren ist KEINE Option!
-
Wie wäre es, wenn du ihm ein Buildsystem zur Installation schickst, statt einem einzelnen, vorkompilierten .so? Du weißt schon, so wie (fast) jede Software? Anscheinend kennst du doch cmake.
edit: Habe den letzten Satz überlesen. Warum ist das keine Option?
-
Dann lass die halt von CMake mit CPack ein Installer als Shellscript erstellen. Normalerweise kopiert CMake dann alle Dateien an den richtigen Ort (man kann auch einen eigenen Prefix angeben, default ist /usr/local glaube ich) (.so's landen in $PREFIX/lib). Außerdem werden die benötigten Dateien gezippt direkt im Script gespeichert. Wie sieht denn deine target_link_libraries Zeile aus?
AlexS2 schrieb:
Naja, dieses CMake setzt automatisch den rpath. Wird dann ja schon einen Sinn haben?
Das hat den Sinn, das man wenn man das Programm kompiliert (auf dem eigenen Rechner, z.B. zum Testen) es nicht erst installieren muss oder LD_LIBRARY_PATH setzen muss.
AlexS2 schrieb:
Zumal ich das gar nicht will - die foo.so braucht ja nur das eine Executable.
Das machen sonst eigentlich alle anderen Programme so.
-
Statisch linken - und ruh is...
Sollte man zwar normalerweise vermeiden - aber in diesem Fall...
