Library in Lazarus

[plusplus]

Ich habe ein DLL in Lazarus geschrieben und gebrauche dynlibs.LoadLibrary, GetProcAddress um den dll zu laden und die funktion aufzurufen.

In windows get alles sehr gut aber in linux und mac nicht. Weis jemand warum dass sein kann?

hier ist ein test projekt: http://gridplusplus.com/downloads/LibTest.rar

[blackfin]

LoadLibrary() und GetProcAddress() sind WinAPI-Funktionen, die es nur unter Windows gibt.
Die Äquivalente in Linux dazu sind dlopen() bzw. dlsym()

[igel457]

Ich sehe jetzt direkt keinen Fehler in deinem Code.

Ich selbst verwende Platformunabhängig (getestet unter Win32, Win64, Linux 32 Bit, Linux 64 Bit) folgenden Code, vielleicht findest du ja einen Unterschied:
http://andorracommons.svn.sourceforg...18&view=markup

Beispielaufrufe:
http://andorracommons.svn.sourceforg...ew=markup#l167

[plusplus]

Zitat von blackfin:

LoadLibrary() und GetProcAddress() sind WinAPI-Funktionen, die es nur unter Windows gibt.
Die Äquivalente in Linux dazu sind dlopen() bzw. dlsym()

Danke fuer den hinweis, daher habe Ich ja dynlibs.LoadLibrary geschrieben, das soll ja der cross function sein.

[plusplus]

Zitat von igel457:

Ich sehe jetzt direkt keinen Fehler in deinem Code.

Danke fuer die quelle, Ich habe es mir angeschaut und Ich denke dass Ich das selbe mache. Um den Float Point problem zu ueberkommen kann man ja auch SafeLoadLibrary gebrauchen.
Was Ich aber nicht verstehe ist dass mein code nicht auf Linux und Mac funkzioniert. Ich habe schon beinahe die ganze lazarus forum nach gesehen, nix, nada. Echt komisch, Ich weis dass loadlibrary geht aber GetProcAddress scheint den entrypoint nicht zu finden, Ich denke dass linux/mac den namen anders exportiert.

[himitsu]

versuch mal

Delphi-Quellcode:

unit lib;

...

exports
   callme name 'callme';

Ich weiß von C-Compilern, daß sie gerne noch die Parameter mit in den Exportnamen einkodieren/anhängen.
Eventuell macht Lazarus FreePascal das hier auch, wenn man diesen den Namen generieren läßt.

Eventuell würde ein Blick in eine fertig kompilierte Linux-DLL (oder wie die da heißen) klarheit schaffen.

[implementation]

Zitat von himitsu:

Linux-DLL (oder wie die da heißen)

Shared Object, kurz SO, Dateiendung .so
unter Mac Dynamic Library, Dateiendung .dynlib

[plusplus]

Ich habe eine loesung gefunden,
1. alle methods muessen in the library unit exportiert werden.
2. auf Linux und Mac ist es besser um cdecl zu benuzten
3. um grosse string zu unterstuetzen muss man cmem als erstes in the uses clause eingeben fuer beide lib und lib gebraucher.

Also es funkzioniert.

Code:

library test;
...

exports //<- hier einlegen

begin
end.

[himitsu]

Zitat:

3. cmem

Das ist eigentlich überall so, wo der Speichermanager standardmäßig nicht geteilt wird.
> siehe ShareMem und Co.