Linking funktioniert nicht (Linux)

CMB

Hoi,

ich versuche gerade ein größeres Projekt (C++/Qt) zu bauen in dem ich mit einer Studentin von mir coden will. Auf meinem Rechner: Keine Probleme. Auf ihrem klappt es nicht shared object files einzubinden. Wir arbeiten beide unter Ubuntu 11.04.

Basteln an den PATH-Variablen hat keinen Effekt. Sämtliche Fremdlibraries (bzw. die .so-Files davon) werden erkannt. Eigene nicht. Und zwar auch dann nicht, wenn das Executable in dem Verzeichnis ausgeführt wird, in dem es liegt und die fraglichen .so-Files da hineinkopiert werden! D. h. sie liegen im selben Verzeichnis wie das Executable und dennoch kein Erkennen?

Woran kann das liegen? Was könnte man ggf. versuchen um das Problem zu beheben?

Jeder Tipp ist willkommen - mir fällt gerade nichts mehr ein.

Gruß & Dank,
Christian

rüdiger

Versuch mal den Fehler besser zu beschreiben. Welche Fehlermeldung bekommst du wenn du was tun willst? Wenn du ein Executable bekommst, dann klingt da ja so, als würde das linken klappen. Wenn der Laufzeitlinker die Bibliothek nicht findet, dann schau dir mal die Umgebungsvariable LD_LIBRARY_PATH an.

C++ Forumbot

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Compiler- und IDE-Forum verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

CMB

Danke. Und entschuldigt die falsche Platzierung des Threads.

Vielleicht hätte ich deutlicher sein sollen: LD_LIBRARY_PATH anpassen hatte keinen Effekt. '$ ldd <executable>' bringt für die fraglichen Files ein schlichtes 'not found', bzw. './executable' ergibt 'error while loading shared libraries' - obwohl die fraglichen Files (ich habe sogar die Namen Zeichen für Zeichen überprüft) im Verzeichnis des Executables liegen.

Und, wie gesagt, auf meinem eigenen Rechner spricht ldd bzw. ldconfig auf LD_LIBRARY_PATH so an, wie zu erwarten ist. Auf dem Rechner einen Platz weiter nicht (bzw. korrekte Einträge in 'env' haben nicht das gewünschte Resultat). Natürlich klingt das seltsam - was vor Moderation des Threads auch für Spott gesorgt hat - gerade deshalb bin auch so ratlos.

Danke auch für die Moderation!

CMB schrieb:

was vor Moderation des Threads auch für Spott gesorgt hat

war kein spott, eher ein vorschlag was du aus deiner beschissenen situation machen kannst...

SeppJ

Ein paar Grundlagen: Bibliotheken werden unter Linux nicht im aktuellen oder im Executableverzeichnis gesucht! Das aktuelle Verzeichnis oder das Verzeichnis der Exe haben keinerlei Sonderbedeutung (außer dass relative Pfadangaben beim aktuellen Verzeichnis losgehen). Du denkst an Windows und sieh, zu was das führt:
Google: windows dll load hijacking

Der LD_LIBRARY_PATH wird zwar oft als falscher Ansatz zur Lösung von Suchpfadproblemen dargestellt, ist bei dem von dir beschriebenen Fall jedoch das richtige Mittel. Sei dir sicher, dass du ihn auch korrekt gesetzt hast. In einem Bashscript musst du Variablen beispielsweise mit export kennzeichnen, damit sie auch nach Beenden des Scripts noch gültig sind. Mach mal ein echo auf den Suchpfad, bevor du ein ldd auf die Datei machst.

Ihr könntet auch beim Linken der Anwendung einen rpath angeben ( gcc -R /pfad/zur/lib ... ). Das ist dann ein Suchpfad speziell nur für diese Anwendung.

Oder ihr installiert die Bibliotheken einfach in den Standardsuchpfaden . Wenn ihr die selber geschrieben habt, dann solltet ihr euch doch wohl auch selber vertrauen können.