Einbinden von .so Android Library in Delphi

[Mark7]

Ich möchte eine .so (shared Object) Library auf Android unter Delphi einbinden.
Dazu möchte ich unter Linux die Datei libswe.so erstellen
(ein Makefile und die entsprechenden Dateien gibt es hier: https://www.astro.com/ftp/swisseph/src/).

Wie erstelle ich die libswe.so und wie kann ich die Funktionen in Delphi aufrufen?

Wenn ich das versuche mit z.B. procedure swe_close;external 'libswe.so'; kommt eine Fehlermeldung " -lswe nicht gefunden".
Scheint ein Link Problem zu sein !?

Hat jemand schon etwas ähnliches umgesetzt?

Schonmal vielen Dank für Hilfe

[TurboMagic]

Hallo,

ich glaube das funktioniert so wie das Erstellen von DLLs für Windows.

Grüße

TurboMagic

[Harry Stahl]

Du gehst da über Datei, Neu, weitere und im angezeigten Dialog wählst Du dann "Geräteübergreifend" und da Dynamische Bibliothek", siehe auch anlg. Screenshot.

Danach musst Du die Android Plattform noch hinzufügen und die .so Datei ist sofort kompilierbar.

Beim einbinden Deiner .so Datei in Deine App muss noch unterschieden werden, ob Du die DLL statisch einbindest oder erst zu Laufzeit.

Wenn statisch, muss Delphi zur Compilierzeit die .so-Datei auffindbar vorliegen haben, damit die entsprechenden Sprungadressen in Dein Code eingebunden werden können. Ich habe leider vergessen wo genau die .so-Datei liegen muss. Falls die Angabe des Suchpfades zu dem Ordner, wo Deine App erzeugt wird, nicht reicht, könnte es auch an einem anderen Ort sein, bzw. eine Angabe an anderer Stelle erforderlich sein (z.B. im Bibliothekspfad oder so?).

Aber evtl. weiß dass jemand anders hier, ich kann mich leider nicht mehr erinnern, hatte mal vor ein paar Monaten so einige Tests mit der Einbindung von Crossplatform DLL's gemacht...

[Mark7]

Vielen Dank schonmal.
Wenn ich die library statisch einbinden will, muss ich sie dann als .dll zur Verfügung stellen?

[TurboMagic]

Hallo,

mit einer DLL kann Android nichts anfangen. Das heißt dort Static Object
und hat die Dateiendung .so. Das ist auch, was Delphi dir erzeugt wenn du
ein DLL Projekt mit Zielplattform Android anlegst und compilierst.

Diese .so muss dann mittels Deployment Manager an die richtige Stelle
(evtl. siehst du dort schon andere .so Dateien gelistet und kannst davon
die Stelle abgucken) und kann dann so wie du unter WIndows eine DLL statisch
benutzen würdest auch benutzt werden.

Grüße
TurboMagic

[Mark7]

@ Harry Stahl:
Ich habe jetzt die libswe.so eingebunden (siehe Bild).
Beim Compilieren bekomme ich noch eine Fehlermeldung.
Woran könnte das liegen?

[Harry Stahl]

Du musst auf verschiedene Dinge achten:

1. Deine App und Deine .libXXX.so Datei müssen beide als 32 oder 64 Bit app/lib compiliert werden.

2. In Deiner libXXX.so muss die gewünschte Funktion "exportiert" werden. Beispiel:

Delphi-Quellcode:

library CrossPlatt;

uses
  System.SysUtils,
  System.Classes;

{$R *.res}

  Function Calc (A, B: Integer): Integer;
  begin
    Result := A * B;
  end;

  exports
    Calc;

begin
end.

3. Deine App importiert diese Funktion so:

Function Calc (A, B: Integer): Integer; external 'libCrossPlatt.so'; Dabei ist wirklich sorgsam darauf zu achten, dass auch alle Parameter exakt angegeben werden, wie in der .libbXXX.so
Datei. Groß und Kleinschreibung ist relevant!

4. Und - ich hatte es dunkel tatsächlich richtig in Erinnerung - Du musst unter Tools, Bibliothekspfad, das Verzeichnis angeben, wo die .libXXX.so Datei erzeugt wurde (siehe Anlage).

Dann klappt es mit der Kompilation, habe es gerade selber noch mal getestet.

Zum Schluss noch ein Hinweis - damit Du Dir nicht umsonst arbeit machst, falls Du das noch nicht wusstest: Du kannst in den .libXXX.so keine Formulare oder sowas unterbringen, das geht nur unter Windows. Du musst Dich also auf reine Funktionen beschränken, die irgendwas berechnen oder Daten verarbeiten und Dir dann das Ergebnis zurückgeben (jedenfalls war dies das Ergebnis meiner Tests und Recherchen von vor einiger Zeit, wer es anders weiß, ich lasse mich auch gerne belehren).

Ich persönlich binde meine (Linux) .libXXX.so oder MAC (.dylibs) alle immer zur Laufzeit ein. Das hat den Vorteil, dass man auch einfach mal die "DLL" austauschen kann, ohne das Programm neu kompilieren zu müssen, bzw. man kann flexibel zur Laufzeit evtl. alternative DLL's laden.