libmylib.so: file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
0000000000000ae0 g DF .text 0000000000000005 mylib_d
0000000000000ab0 g DF .text 0000000000000005 mylib_a
0000000000000ac0 g DF .text 0000000000000005 mylib_b
0000000000000000 D *UND* 0000000000000000 caller
0000000000000ad0 g DF .text 0000000000000005 mylib_c
*snip*
This very same approach works if there is no calling of the main program's function, or if it is done by passing it's address to the library. Introducing thepart resulted in LoadLibrary being unable to open the library. If i do `objdump -T libmylib.so`, the symbols are seem to be in their place and the library's name is correct too:
type TCaller = function (ptr: pinteger): integer; cdecl; var caller: TCaller; external name 'caller';Code: [Select]libmylib.so: file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
0000000000000ae0 g DF .text 0000000000000005 mylib_d
0000000000000ab0 g DF .text 0000000000000005 mylib_a
0000000000000ac0 g DF .text 0000000000000005 mylib_b
0000000000000000 D *UND* 0000000000000000 caller
0000000000000ad0 g DF .text 0000000000000005 mylib_c
I don't have time to go through your code or understand the issue and you do not mention the OS, but you can look at what I wrote with code examples for macOS (UNIX) in this Wiki article (https://wiki.lazarus.freepascal.org/macOS_Dynamic_Libraries).Thank you, but what you've covered in your article (creating a library and calling it's functions) is already working in my test setup. What does not is the "callback" mechanism, when the library calls a function of the dynamically linked executable. (The statical - where i simply give the function's address to the library - is working.)
Isn't it that the 'caller' variable was declared as pointer to fn in mylib, while the 'caller' in mytest is just a function, not a var?It has to be a var which points to a function, since the function does not exists in the library. It works in C, if the executable is linked dynamically. This is in the C lib:
Have you set the LD_LIBRARY_PATH env variable?No, but it is not needed in this case, as i used the full path to the library, not just it's name.
*snip*I'm a bit confused!Isn't it that the 'caller' variable was declared as pointer to fn in mylib, while the 'caller' in mytest is just a function, not a var?It has to be a var which points to a function, since the function does not exists in the library. It works in C, if the executable is linked dynamically. This is in the C lib:And this is in the C executable:
extern int caller(int *ptr); int mylib_d(int *d); int mylib_d(int *d) { *d += 5; return caller(d); }This approach also works in the statically linked Pascal executable, although i have to set that variable manually via a setter function of the library.
int caller(int *ptr) { *ptr += 5; return *ptr + 5; }Have you set the LD_LIBRARY_PATH env variable?No, but it is not needed in this case, as i used the full path to the library, not just it's name.
I'm a bit confused!You're right, i confused it. In the statical version it was.Is not a variable definition. But:
extern int caller(int *ptr);is.
var caller: TCaller; external name 'caller';
Also, objdump -T mytest doesn't show caller as a dynamic symbol.Weird. It did for me.
Use:Thank you, it works perfectly!into mytest.pas and:
exports caller;into mylib.pas.
//type TCaller = function (ptr: pinteger): integer; cdecl; //var caller: TCaller; external name 'caller'; function caller(ptr: pinteger): integer; cdecl; external name 'caller';
Otherwise, you'll get an EAccessViolation.
*snip*You're welcome!
Thank you, it works perfectly!
I am experimenting with libraries and i wanted to try out the dynamically linked executable setup too. I have a version where i pass the function's pointer to the library.*snip*You're welcome!
Thank you, it works perfectly!
Yet I'm wondering why such weird back-ref to the 'caller' used? I would pass the pointer to it as a parameter to the mylib_d().