Libary in den Standardpath "systemweit" einfügen?
-
Kommt auf die Distribution an, aber meistens liegt die Konfiguration von ld in
/etc/ld.so.conf
. Dort kann root systemweit die Standardpfade ändern, wenn er genau weiß, was er da tut.Aber ich glaube, du suchst wohl eher "LD_RUN_PATH" für den Übersetzungsvorgang.
-
Hallo,
erstmal vielen Dank für eure Antworten.
Ich benutze Ubuntu und nein, ich weiß nicht was ich mache - bin noch neu in Linux.
Was ist denn die "eleganteste" Vorgehensweise dafür , bzw. was ist "üblich" ?
Lg
-
Krelinn schrieb:
Hallo,
erstmal vielen Dank für eure Antworten.
Ich benutze Ubuntu und nein, ich weiß nicht was ich mache - bin noch neu in Linux.
Was ist denn die "eleganteste" Vorgehensweise dafür , bzw. was ist "üblich" ?
Lg
Das kommt eben drauf an, ob das Vorhaben wirklich ist
1. "Die Systempfade für alle Nutzer verändern"
oder
2. "Dieses eine Programm soll seine Bibliotheken woanders suchen".Oder Möglichkeit 3: Die Bibliotheken dort installieren, wo sie gefunden werden.
Oder Möglichkeit 4: Sicherstellen, ob das überhaupt das Problem ist (denn /usr/local/lib ist eigentlich ein oft benutzter Standardsuchpfad).
Lösung für 4: Mach mal auf einer Konsole
ldconfig -v 2>/dev/null | grep -v ^$'\t'
Wird eine Weile dauern. Ist da tatsächlich kein /usr/local/lib dabei?
Zu 3: Kommt drauf an, wie sie überhaupt dort hin gekommen sind. Normalerweise kann man Installationspfade aber anpassen.
Zu 2:
"-Wl,-rpath /usr/local/lib" als Schalter beim Linken mitgeben (Wenn der Linker über den GCC aufgerufen wird. Bei direktem Aufruf von ld nur "-rpath /usr/local/lib")Zu 1: Die genannte Datei ändern.
-
Hallo Sepp, nochmal danke für deine Antwort.
SeppJ schrieb:
Zu 3: Kommt drauf an, wie sie überhaupt dort hin gekommen sind. Normalerweise kann man Installationspfade aber anpassen.
Also ich habe die Grafiklib (es handelt sich um die Simple Fast Media Libary) über Github geladen und dann mit make && make install ) installiert. Ich habe mal in die make install Datei geschaut und dort ist öfters auch eben usr/local/lib angegen. Das scheint also das Standardpfad für Applikationen dieser Bibliothek zu sein.
SeppJ schrieb:
Lösung für 4: Mach mal auf einer Konsole
ldconfig -v 2>/dev/null | grep -v ^$'\t'
Wird eine Weile dauern. Ist da tatsächlich kein /usr/local/lib dabei?
Also Nach dem ich dem Befehl eingegeben habe listet er mir folgendes auf
/usr/lib/i386-linux-gnu/mesa: /lib/i386-linux-gnu: /usr/lib/i386-linux-gnu: /usr/local/lib: /lib/x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/mesa-egl: /usr/lib/x86_64-linux-gnu/mesa: /lib: /usr/lib:
Ich hatte das früher schon mal auf Ubuntu installiert und da erinnere ich mich, dass es eigentlich sofort funktioniert hat.
Lg
-
Also Variante 4: Es liegt an was ganz anderem.
Daher: Beschreibe was du tust, was du erwartest, was stattdessen passiert. Jeweils ganz genau und vollständig. Eventuellen Code bitte zu einem compilierbaren Minimalbeispiel zusammenschrumpfen, das den Fehler immer noch reproduziert. Siehe meine Signatur.
-
wiso hast du SFML selbst installiert und nicht ein fertiges paket aus dem paketmanager installiert?
http://nomoreterminals.blogspot.de/2012/03/how-to-install-and-start-working-with.html
-
Ich möchte gerne die neusten Builds benutzen und auch nicht auf das Ubuntu Rep. angewiesen sein.
SeppJ schrieb:
Also Variante 4: Es liegt an was ganz anderem.
Daher: Beschreibe was du tust, was du erwartest, was stattdessen passiert. Jeweils ganz genau und vollständig.
Alles klar. Werde jetzt ganz genau auflisten, was ich wie gemacht habe. Also:
Zuerst habe ich mir das neuste SFML-Paket hier runtergeladen: https://github.com/LaurentGomila/SFML (rechts Download-Zip).
Danach habe ich mir Shared-Builds Release und Debug erstellt und installiert.
cmake -G "Unix Makefiles" -D CMAKE_BUILD_TYPE=Release -D BUILD_SHARED_LIBS=TRUE . make sudo make install
cmake -G "Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug -D BUILD_SHARED_LIBS=TRUE . make sudo make install
Jetz habe ich folgenden Quellcode benutzt
#include <SFML/Graphics.hpp> int main() { sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!"); sf::CircleShape shape(100.f); shape.setFillColor(sf::Color::Green); while (window.isOpen()) { sf::Event event; while (window.pollEvent(event)) { if (event.type == sf::Event::Closed) window.close(); } window.clear(); window.draw(shape); window.display(); } return 0; }
Und diesen mit den Befehlen:
g++ -c main.cpp g++ main.o -o test -lsfml-graphics -lsfml-window -lsfml-system
compiliert und gelinkt.
Wenn ich das Programm starte ./test kommt folgender Fehler:
./sfml-app: error while loading shared libraries: libsfml-graphics.so.2: cannot open shared object file: No such file or directory
Wenn ich hingegen so starte geht es:
export LD_LIBRARY_PATH=$PATH:/usr/local/lib && ./test
Allerdings muss ich das Programm dann eben immer so starten. Früher hatte ich das Problem nicht, weil er die Shared-Libary Files direkt gefunden hat, was er jetzt irgendwie nicht mehr tut.
-
Dir ist aber bekannt, dass du dadurch auch unter umständen ungetesteten code verwendest?
Und was spricht dagegen von der version aus dem ubuntu repository abhängig zu sein?
funktioniert es auch wenn du
export LD_LIBRARY_PATH=/usr/local/lib && ./test
machst?
-
firefly schrieb:
Und was spricht dagegen von der version aus dem ubuntu repository abhängig zu sein?
Wenn ich mal die Distro wechsel und/oder die neuste Version brauche stehe ich auf dem Schlauch. Ich will hier gerne unabhängig sein. Außerdem kann es nicht schaden, einfach mal zu wissen, wie es auch alternativ gehen würde.
firefly schrieb:
Dir ist aber bekannt, dass du dadurch auch unter umständen ungetesteten code verwendest?
Ich vertraue hier dem Autor.
firefly schrieb:
funktioniert es auch wenn du
export LD_LIBRARY_PATH=/usr/local/lib && ./test
machst?
Ja.
-
Führ mal
sudo ldconfig -v
aus. Das aktualisiert die Liste aller Shared Libraries in den eingetragenen Suchpfaden. Da /usr/local/lib bei dir anscheinend schon dazu zählt (siehe oben), sollte das auch die SFML-Bibliotheken erwischen.
Eigentlich hätte das bei der Installation erledigt werden sollen, aber vielleicht ist etwas schief gelaufen.
Danach übersetze das Programm noch einmal neu und starte es ganz normal, ohne LD_LIBRARY_PATH.
-
SeppJ schrieb:
Führ mal
sudo ldconfig -v
aus. Das aktualisiert die Liste aller Shared Libraries in den eingetragenen Suchpfaden. Da /usr/local/lib bei dir anscheinend schon dazu zählt (siehe oben), sollte das auch die SFML-Bibliotheken erwischen.
Eigentlich hätte das bei der Installation erledigt werden sollen, aber vielleicht ist etwas schief gelaufen.
Danach übersetze das Programm noch einmal neu und starte es ganz normal, ohne LD_LIBRARY_PATH.
Es geht *freu* ! Ganz ehrlich, du bist mein Held. Ich hab schon so viele Leute gefragt ....
Ganz herzliches Dankeschön !