[GNU/Linux, FPC] SO's einbinden

[implementation]

Ich habe jetzt unter Linux mit dem FPC eine kleine Testbibliothek geschrieben:

Delphi-Quellcode:

// Cray.pas
library Cray;

uses CrayLib, CrayInter;

procedure println(s: pchar);
begin
   WriteLn(String(s));
end;

exports println;

end.

Wenn ich sie kompiliere kommt auch wie gewünscht die 'libCray.so' raus.

Nun möchte ich sie einbinden:

Delphi-Quellcode:

// Crayfish.pas
unit Crayfish;

interface

uses CrayInter;

procedure println(s: pchar); external 'Cray' name 'println';

implementation

end.

// CrayExample.pas
program CrayExample;

uses Crayfish, CrayInter;

begin
   println('o.O');
end.

Ich kompiliere CrayExample und starte es.
Nun kommt jedoch die Meldung, libCray.so könne nicht gefunden werden.
Die SO liegt im gleichen Verzeichnis.

Woran liegt das?


[EDIT]
Habe jetzt die libCray.so mal nach /lib verschoben. Jetzt funktioniert's.
Werden Bibliotheken etwa nur dort erkannt?
Na das macht das Debuggen ja nicht gerade einfacher, wenn man sich nach jeder Kompilierung erstmal ein sudo erkämpfen muss, um die Bibliothek zu verschieben
Als Sicherheitsmaßnahme ist es wohl sinnvoll, das verstehe ich ja.

Gibt es sonst keine andere Möglichkeit?

[wicht]

Hi,

habe auch nicht so die Ahnung davon, aber vielleicht hilft ldconfig wie hier beschrieben weiter?

HTH

[implementation]

Sieht ganz interessant aus.

Funktioniert nur noch nicht so ganz bei mir

Habe den Pfad eingetragen und ldconfig drüberlaufen lassen.
Aber die SO ist trotzdem noch nicht gefunden.

[Klaus01]

Guten Abend,

Vielleich kannst Du ja den LD_LIBRARY_PATH für Deine Userkennung erweitern.

Grüße
Klaus

[fkerber]

Hi,

war das nicht genau das, was man nicht tun sollte?


LG, Frederic

[igel457]

Zum Testen und Entwickeln von Software ist das IMHO legitim.

Auch die Betas von Firefox machen das z.B. so: Lädt man sich ein Binärpaket davon herunter, so ist dem eigentlichen "firefox-bin"-Executable ein "firefox"-Bash-Script vorgeschaltet, dass LD_LIBRARY_PATH entsprechend setzt.

[implementation]

Zitat von fkerber:

Hi,

war das nicht genau das, was man nicht tun sollte?

LG, Frederic

Natürlich ist das ein Sicherheitsrisiko, einen Pfad hinzuzufügen, für den man keine Admin-Berechtigung benötigt.
Das macht es Schadsoftware leichter.

Aber beim Entwickeln ist es wirklich lästig, dauernd die SO nach /lib kopieren zu müssen und daher gehe ich das Risiko halt ein.

Zitat von Klaus01:

Guten Abend,

Vielleich kannst Du ja den LD_LIBRARY_PATH für Deine Userkennung erweitern.

Grüße
Klaus

Ist das eine Umgebungsvariable? Bei mir gibt's die irgendwie nicht

[fkerber]

Hi,

ein

Code:

export LD_LIBRARY_PATH=Pfad/zur/so:$LD_LIBRARY_PATH

auf der Console sollte es eigentlich tun.


LG, Frederic

[Assarbad]

Zitat von implementation:

Werden Bibliotheken etwa nur dort erkannt?

Das läßt sich einstellen. Siehe: man ld.so

Am besten nimmst du ein Wrapper-Skript. Ich nehme an, daß deine Anwendung CrayExample heißt und die .so libCray.so. Desweiteren nehmen wir an, daß .so und Binary im gleichen Verzeichnis liegen:

Code:

#!/usr/bin/env bash
# Hier den Pfad zu deinem Programm
CRAY_APP=/home/bla/foo/bar/CrayExample
LD_PRELOAD=`dirname $CRAY_APP`/libCray.so $CRAY_APP

Vereinfacht kannste auf der Shell auch das machen:

Code:

LD_PRELOAD=./libCray.so ./CrayExample

Wie gesagt, RTFM: man ld.so

[Assarbad]

Kleiner Hinweis noch zu der Syntax. Wenn in einem (Bash)Skript (andere Shells haben zT andere Syntax) benutzt, wird:

Code:

VARIABLE=WERT

die Umgebungsvariablen nur innerhalb des Skripts beeinflussen. Danach kann man entweder explizit:

Code:

export VARIABLE

ausführen, was die portablere Variante ist von (Bash):

Code:

export VARIABLE=WERT

Solange du das Skript (bspw. foo.sh) nicht "sourcst" ("to source"), also

Code:

source foo.sh
# ... oder
. foo.sh

... ausführst, wird die Umgebung deiner aktuellen Shellsitzung nicht beeinflußt.

Verkürzt geht auch:

Code:

VARIABLE=WERT PROGRAMM

welches die VARIABLE auf WERT setzt und zwar einzig für diesen Aufruf von PROGRAMM.

Subshells sind dann eventuell für diverse Sachen auch sinnvoll ...