Re: [fpc-pascal] FFI or RTTI invoke for Apple arm64
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?) On Wed, Aug 19, 2020, at 16:01, Carlo Kok via fpc-pascal wrote: > 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! > > On Wed, Aug 19, 2020, at 14:09, Sven Barth via fpc-pascal wrote: >> Carlo Kok via fpc-pascal schrieb am Mi., >> 19. Aug. 2020, 13:17: >>> 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? >> >> 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 >>> >> ___ >> fpc-pascal maillist - fpc-pascal@lists.freepascal.org >> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >> > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Using built-in serial instead of synaser and the like for Linux console app?
On Tue, 1 Sep 2020 20:31:57 +0200 (CEST), Michael Van Canneyt via fpc-pascal wrote: >Yes, but you can only override a virtual constructor. The TThread >constructor is not virtual. I am doing the setup in a different way so I don't have to use Create. My new FpSerialPort works fine now with the simple test application. But now I have to plug it into the larger service app I am porting and I have come across a piece of code where the alternative com port classes used on Windows have a way to check how many bytes are in the outgoing buffer ready to be transfered. The existing code waits until there are less than 16 bytes left to transfer before it fills the Tx buffer with another packet of 512 bytes. In order to do this it checks the state of the Tx buffer: Using LazSerial (Windows and Linux): while FComm.SynSer.SendingData > 16 do (waiting for it to empty) Using AsyncPro (Windows): while FComm.OutBuffUsed > 16 do Using an older but simpler serial comp on Windows: while FComm.TxWaiting > 16 do Is there anything comparable available via the serial unit? I have not found anything so I guess it has to be an addition to get it done The binary data to send can in worst case be 1 Mbytes in size even though normally it varies between 1 and a few hundred bytes per operation. Any suggestions? -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcmake packaging
> On Sep 1, 2020, at 9:04 PM, Tony Whyman via fpc-pascal > wrote: > > My primary motivation for going with fpcmake is that it is a very good fit > with the debian package management system (and rpmbuild). My normal build > target is Ubuntu and hence I want to generate .deb files in order to > distribute my application. The Debian Package Manager does not actually > mandate use of makefiles - but it is built around the makefile concept and I > have only ever seen examples of use based on makefiles. Thanks for the detailed explanation. It's pretty intimidating but I guess I need to try since it appears to do what I want. You said I can call external scripts which is pretty interesting also because I may have some edge cases with macOS stuff. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FFI or RTTI invoke for Apple arm64
Carlo Kok via fpc-pascal schrieb am Mi.,
2. Sep. 2020, 11:09:
> 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?)
>
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
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FFI or RTTI invoke for Apple arm64
On Wed, Sep 2, 2020, at 14:40, Sven Barth via fpc-pascal wrote:
> Carlo Kok via fpc-pascal schrieb am Mi., 2.
> Sep. 2020, 11:09:
>> __
>>
>> 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?)
>
> 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.
>
Thanks. It doesn't look like it's officially supported:
https://sourceware.org/libffi/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FFI or RTTI invoke for Apple arm64
Carlo Kok via fpc-pascal schrieb am Mi.,
2. Sep. 2020, 15:01:
> On Wed, Sep 2, 2020, at 14:40, Sven Barth via fpc-pascal wrote:
>
> Carlo Kok via fpc-pascal schrieb am
> Mi., 2. Sep. 2020, 11:09:
>
>
>
> 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?)
>
>
> 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.
>
>
> Thanks. It doesn't look like it's officially supported:
>
> https://sourceware.org/libffi/
>
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
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] String literals and code page of .pas source file
Hi *,
I would like to have source file in Windows-1250 encoding, where are
stored literal strings like 'áéíóčž' in Windows-1250 encoding (I share
this one file between FPC/Lazarus and Delphi 7). Windows-1250 is also
ANSI code page of my Windows OS. In source file I have:
{$IFDEF FPC}
{$CODEPAGE cp1250}
{$ENDIF}
and in Lazarus I have set: File settings / Encoding / CP1250
(at this point in .pas file are all characters correctly encoded in
Windows-1250 code page)
When I compile application and run it, string literals (characters with
accents) are not preserved.
Is there way how to get it working?
Only work-around which worked for me (in both Delphi and Lazarus) was use:
const
STRINGLITERAL1: WideString = 'áéíóčž';
Thanks
-Laco.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
