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$_$TFFIFUNCTIONCALLBA
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
> 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
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
>
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
>
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
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}
{$COD
