[GNU/Linux, FPC] SO's einbinden

[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 ...

[JamesTKirk]

Alternativ zum Linken mit external 'libname' name 'symbol'; (shared linking) könntest du die SO auch dynamisch laden (siehe hierzu die Unit dynlibs), dann kannst du nämlich den absoluten Pfad zur Bibliothek angeben.

Wenn du dich noch ein wenig mit Compilerbedingungen ({$ifdef ...} ) rumschlägst, dann kannst du zwischen shared und dynamic linking für Release- bzw. Entwicklungsversionen umschalten.

Gruß,
Sven