Hi,
for PascalScript FFI support, are there plans to support RTTI .Invoke, or any form of FFI available to do dynamic invoke from Pascalscript to FPC/api code?

Mailing lists / fpc-pascal / 2020-08
8 messages · 3 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Hi,
for PascalScript FFI support, are there plans to support RTTI .Invoke, or any form of FFI available to do dynamic invoke from Pascalscript to FPC/api code?
Carlo Kok wroteHi, for PascalScript FFI support, are there plans to support RTTI .Invoke, or any form of FFI available to do dynamic invoke from Pascalscript to FPC/api code?
As far as I know, the RTTI.Invoke is there. There are even tests for it. We use libffi for it.
I don't know if it made it into 3.2, Sven Barth can inform better about this.
Michael.
for PascalScript FFI support, are there plans to support RTTI .Invoke, or any form of FFI…
Carlo Kok via fpc-pascal schrieb am Mi.,
19. Aug. 2020, 13:17:
Rtti.Invoke is available in 3.2.0 however for all platforms except for Win64 and the register calling convention on i386 the libffi library is used. Officially libffi does not yet seem to support macOS on Aarch64 however it supports iOS, so you'll need to check whether you can get a variant working for macOS on Aarch64.
Alternatively you'd need to implement a custom function call manager for Aarch64.
Regards,
Sven
It looks like I misread the error completely, and presumed, from the include logic that it was x86_64 / x86 only. It compiles now, thanks!
Seems I had to use ffi.manager.pas too. However when building then it fails with;Undefined symbols for architecture arm64:
"_ffi_call", referenced from:
_FFI.MANAGER_$$_FFIINVOKE$crc7AE31AA0 in ffi.manager.o "_ffi_closure_alloc", referenced from:
_FFI.MANAGER$_$TFFIFUNCTIONCALLBACK_$__$$_CREATE$crc5C7D27E4 in ffi.manager.o "_ffi_closure_free", referenced from:
_FFI.MANAGER$_$TFFIFUNCTIONCALLBACK_$__$$_DESTROY in ffi.manager.o "_ffi_prep_cif", referenced from:
_FFI.MANAGER_$$_CREATECIF$crcD3E75E66 in ffi.manager.o "_ffi_prep_closure_loc", referenced from:
_FFI.MANAGER$_$TFFIFUNCTIONCALLBACK_$__$$_CREATE$crc5C7D27E4 in ffi.manager.o "_ffi_type_double", referenced from:
_FFI.MANAGER_$$_TYPEINFOTOFFITYPE$PTYPEINFO$TPARAMFLAGS$$PFFI_TYPE in ffi.manager.o "_ffi_type_float", referenced from:
_FFI.MANAGER_$$_TYPEINFOTOFFITYPE$PTYPEINFO$TPARAMFLAGS$$PFFI_TYPE in ffi.manager.o "_ffi_type_pointer", referenced from:
_FFI.MANAGER_$$_TYPEINFOTOFFITYPE$PTYPEINFO$TPARAMFLAGS$$PFFI_TYPE in ffi.manager.o "_ffi_type_sint16", referenced from:
_FFI.MANAGER_$$_TYPEINFOTOFFITYPE$PTYPEINFO$TPARAMFLAGS$$PFFI_TYPE in ffi.manager.o "_ffi_type_sint32", referenced from:
_FFI.MANAGER_$$_TYPEINFOTOFFITYPE$PTYPEINFO$TPARAMFLAGS$$PFFI_TYPE in ffi.manager.o "_ffi_type_sint64", referenced from:
_FFI.MANAGER_$$_TYPEINFOTOFFITYPE$PTYPEINFO$TPARAMFLAGS$$PFFI_TYPE in ffi.manager.o "_ffi_type_sint8", referenced from:
_FFI.MANAGER_$$_TYPEINFOTOFFITYPE$PTYPEINFO$TPARAMFLAGS$$PFFI_TYPE in ffi.manager.o "_ffi_type_uint16", referenced from:
_FFI.MANAGER_$$_RECORDOROBJECTTOFFITYPE$PTYPEINFO$$PFFI_TYPE in ffi.manager.o _FFI.MANAGER_$$_SETTOFFITYPE$INT64$$PFFI_TYPE in ffi.manager.o _FFI.MANAGER_$$_TYPEINFOTOFFITYPE$PTYPEINFO$TPARAMFLAGS$$PFFI_TYPE in ffi.manager.o "_ffi_type_uint32", referenced from:
_FFI.MANAGER_$$_RECORDOROBJECTTOFFITYPE$PTYPEINFO$$PFFI_TYPE in ffi.manager.o _FFI.MANAGER_$$_SETTOFFITYPE$INT64$$PFFI_TYPE in ffi.manager.o _FFI.MANAGER_$$_TYPEINFOTOFFITYPE$PTYPEINFO$TPARAMFLAGS$$PFFI_TYPE in ffi.manager.o "_ffi_type_uint64", referenced from:
_FFI.MANAGER_$$_RECORDOROBJECTTOFFITYPE$PTYPEINFO$$PFFI_TYPE in ffi.manager.o _FFI.MANAGER_$$_SETTOFFITYPE$INT64$$PFFI_TYPE in ffi.manager.o _FFI.MANAGER_$$_TYPEINFOTOFFITYPE$PTYPEINFO$TPARAMFLAGS$$PFFI_TYPE in ffi.manager.o "_ffi_type_uint8", referenced from:
_FFI.MANAGER_$$_RECORDOROBJECTTOFFITYPE$PTYPEINFO$$PFFI_TYPE in ffi.manager.o _FFI.MANAGER_$$_SETTOFFITYPE$INT64$$PFFI_TYPE in ffi.manager.o _FFI.MANAGER_$$_TYPEINFOTOFFITYPE$PTYPEINFO$TPARAMFLAGS$$PFFI_TYPE in ffi.manager.o "_ffi_type_void", referenced from:
_FFI.MANAGER_$$_TYPEINFOTOFFITYPE$PTYPEINFO$TPARAMFLAGS$$PFFI_TYPE in ffi.manager.o _FFI.MANAGER_$$_CREATECIF$crcD3E75E66 in ffi.manager.o ld: symbol(s) not found for architecture arm64
Is there something else I need to do to allow FFI to work on arm64? (Does this depend on a dylib? or a static library?, and do I need to explicitly reference that?)
Carlo Kok via fpc-pascal schrieb am Mi.,
2. Sep. 2020, 11:09:
You need the libffi library compiled for macOS on ARM ( https://github.com/libffi/libffi ) and then you might need to add a "{$linklibrary ffi}" or so, cause the ffi unit was not set tested on macOS.
Regards,
Sven
Thanks. It doesn't look like it's officially supported:
Carlo Kok via fpc-pascal schrieb am Mi.,
2. Sep. 2020, 15:01:
The calling convention is the same as on iOS, so you can try to build it for that target... (and build from their development version on GitHub)
Regards,
Sven