.so-Bibliotheken im gleichen Verzeichnis suchen



  • Hallo Forumnutzer,

    ich habe folgende Ordner-/Dateistruktur:

    O: bin
       O: lib
          L: libGL.so
          L: libGLEW.so
          L: libGLU.so
          L: libGLUT.so
       D:main (eigentliches Programm)
       D:run.sh
    O:src
       D:(Source-Dateien .cpp)
    D:compile.sh
    

    Hier gilt: O=Ordner D=Datei(+ausführbar) L=Bibliothek (.so)

    Das Programm wurde zunächst mit folgender Befehlszeile (=compile.sh) kompiliert:

    g++-5 src/main.cpp -o bin/main -ansi -std=c++11 -L"./bin/lib" -l GLEW -l GLU -l GLUT -l GL
    

    Wenn ich dann run.sh ausführe, funktioniert zunächst alles:

    ./main
    

    Nun möchte ich allerdings erreichen, dass bei dem Kopieren des kompletten Ordners bin auf einem anderen Computer bspw. main (das Programm) trotzdem relativ auf die Bibliotheken im lib-Ordner zugreift und nicht im "System-Bibliotheken-Ordner" sucht.

    Wie kann ich also szs. "relativ" bzw. "dynamisch" linken?
    Ist -Wl,-rpath evtl. die richtige Lösung?

    Danke für die Antworten!

    Mit freundlichen Grüßen
    Seikuassi


  • Mod

    Seikuassi schrieb:

    Ist -Wl,-rpath evtl. die richtige Lösung?

    Ja.

    Ob das eine gute Idee ist, sei aber mal in Frage gestellt.



  • Hallo SeppJ,

    danke für deine Antwort.

    Naja, gute Idee...alle Bibliotheken sollten ja abwärtskompatibel sein.
    Obs sinnvoll ist, sei mal dahingestellt. 😃

    Wie müsste ich denn jetzt, rpath richtig anwenden, damit eben der bin-Ordner nachher auf andere Computer bspw. kopiert werden können und ohne Fehler ausgeführt werden?

    Ich wäre dankbar für eine Beispielsbefehlszeile (bezogen auf meine Ordnerstruktur).

    Danke nochmal für die Hilfe!

    Mit freundlichen Grüßen
    Seikuassi


  • Mod

    Seikuassi schrieb:

    Naja, gute Idee...alle Bibliotheken sollten ja abwärtskompatibel sein.
    Obs sinnvoll ist, sei mal dahingestellt. 😃

    Das Problem ist ein anderes. Es ist ein erhebliches Sicherheitsrisiko. Windows hat das was du beschreibst als "Feature" und krankt seit seiner Geburt da dran und sie können es nun aus Kompatibilitätsgründen nicht mehr so einfach rausmachen.

    Wie müsste ich denn jetzt, rpath richtig anwenden, damit eben der bin-Ordner nachher auf andere Computer bspw. kopiert werden können und ohne Fehler ausgeführt werden?

    Stopp! Das ist ja wohl eine ganz andere Frage, als wie man in einem relativen Pfad suchen kann. Was du anscheinend wirklich willst ist, dass der bin-Ordner deines Programms durchsucht wird und zwar egal wo man gerade ist. Also das genaue Gegenteil von relativen Pfaden.

    Das ginge auch, aber ist mit einer gewissen Art von Installation verbunden (wodurch dann auch das erwähnte Sicherheitsrisiko eliminiert wird). Und da solche eine Art von Installation durch den Nutzer letztlich immer nötig ist (außer du linkst alles statisch), kannst du es auch gleich richtig machen, anstatt dem Anwender aus falsch verstandener Nutzerfreundlichkeit eine ungewöhnliche und schlecht gemachte eigene Installationsroutine auf zu zwingen. Das ist für dich und den Anwender einfacher. Ansonsten, wie gesagt, statisch linken (und dann dürfen du und der Anwender sich schon einmal auf all die Probleme freuen, die daraus resultieren können).



  • @Seikuassi

    -Wl,-rpath='$ORIGIN/lib'
    

    SeppJ schrieb:

    Wie müsste ich denn jetzt, rpath richtig anwenden, damit eben der bin-Ordner nachher auf andere Computer bspw. kopiert werden können und ohne Fehler ausgeführt werden?

    Stopp! Das ist ja wohl eine ganz andere Frage, als wie man in einem relativen Pfad suchen kann. Was du anscheinend wirklich willst ist, dass der bin-Ordner deines Programms durchsucht wird und zwar egal wo man gerade ist. Also das genaue Gegenteil von relativen Pfaden.

    nein, er will dass die exe immer die libs nimmt, die relativ zur exe im lib-Verzeichnis liegen.
    Das geht mit dem ORIGIN im rpath.

    So muss man das machen, wenn man möglichst viele Distros unterstützen will. Wenn man ganz nett ist, macht man natürlich für jede Distro ein eigenes Paket.



  • Distronator schrieb:

    So muss man das machen, wenn man möglichst viele Distros unterstützen will.

    Nein muss man nicht. Es funktioniert auch mit einem shell script welche LD_LIBRARY_PATH passend setzt bevor das eigentliche Programm gestartet wird.



  • Das geht zwar auch, aber wenn es mit RPATH geht, ist das zu vorzuziehen.

    Beim LD_LIBRARY_PATH muss man sonst beim Aufruf externer Programme aufpassen, ausserdem wird dann eben das Shellscript benoetigt was wiederum eine Shell benoetigt.


Anmelden zum Antworten