[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 :wall:
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.:-D

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:

Zitat von fkerber (Beitrag 1080951)

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:

Zitat von Klaus01 (Beitrag 1080947)

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 :gruebel:

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

Zitat von implementation (Beitrag 1080933)

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 :zwinker:

[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

Delphi-Quellcode:

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 (

Delphi-Quellcode:

{$ifdef ...}

) rumschlägst, dann kannst du zwischen shared und dynamic linking für Release- bzw. Entwicklungsversionen umschalten.

Gruß,
Sven

[implementation]

Zitat:

Zitat von fkerber (Beitrag 1081114)

Hi,

ein

Code:

export LD_LIBRARY_PATH=Pfad/zur/so:$LD_LIBRARY_PATH

auf der Console sollte es eigentlich tun.


LG, Frederic

Will leider auch nicht :?

@JamesTKurk:
Eigentlich wollte ich es hier auf die external-Weise machen, ist hier einfach bequemer.

[Assarbad]

Zitat:

Zitat von implementation (Beitrag 1081423)

Will leider auch nicht :?

LD_PRELOAD? :roll:

Oh und: "man ld.so" ...

[Maik81ftl]

Zitat:

Zitat von implementation (Beitrag 1081423)

Zitat:

Zitat von fkerber (Beitrag 1081114)

Hi,

ein

Code:

export LD_LIBRARY_PATH=Pfad/zur/so:$LD_LIBRARY_PATH

auf der Console sollte es eigentlich tun.


LG, Frederic

Will leider auch nicht :?

@JamesTKurk:
Eigentlich wollte ich es hier auf die external-Weise machen, ist hier einfach bequemer.

Nun diese Bittere Pille habe ich auch schon schlucken müßen.

du hattest gefragt, ob *.so nur im lib Ordner gefunden werden? nun diese Frage ist mit einem KLAREM JAIN zu beantworten. es gibt wie auch schon erwähnt wurde die load.so.con, welche du dir umschreiben/Anpassen mußt. ich persönlich würde davon aber die finger lassen.

Daher mein Tip, wenn dein Proggi Plattform übergreifend Arbeiten soll.

Delphi-Quellcode:

const
  {$IFDEF WIN32}
  Codedll = Phadangabe für Windows;
  {$ELSE}
  Codedll = '/libMyCode.so';
  {$ENDIF}

den Aufruf selber würde ich an deiner Stelle wie folgt aussehen lassen

Delphi-Quellcode:

Function XY(Value: PChar):PChar; {$IFDEF WIN32}stdcall{$ELSE}cdecl{$ENDIF}; External Codedll;

wenn du da auch alle regeln bei der Verwenung in Lazarus beachtest, hast du keine Probleme.

zugegeben, das bei Lazarus keine Sharemem verwendet wird finde ich selber auch schade, Habe bei Delphi gerne mit dem Sharemem geschrieben.