You are not logged in.
Pages: 1
I can confirm that mORMot works fine on Raspberry Pi after the current changes for ARM platform.
Thanks a lot, AOG!
OK, thank you, I will wait for the fix.
Hi,
I tried to run the example project "14 - Interface based services\Project14ServerHttp" on a Raspberry Pi 3B+.
Using fpcupdeluxe, I installed the recommended versions of FPC trunk (rev. 40491) and Lazarus (2.1.0, rev. 59757) on Windows, the cross compiler for Linux/arm, the latest mORMot.
The project builds successfully, but there is an exception at the initialization of the application when I run it on the Pi:
An unhandled exception occurred at $000A34EC:
EAccessViolation: Access violation
$000A34EC GETENUMNAME, line 21167 of C:/FreePascal/ccr/mORMot/SynCommons.pas
$000ADDD0 TOTEXT, line 26120 of C:/FreePascal/ccr/mORMot/SynCommons.pas
$000ADF8C SETLINUXDISTRIB, line 26308 of C:/FreePascal/ccr/mORMot/SynCommons.pas
$000AE6E0 RETRIEVESYSTEMINFO, line 26386 of C:/FreePascal/ccr/mORMot/SynCommons.pas
$00133C84 SYNCOMMONS_$$_init$, line 62842 of C:/FreePascal/ccr/mORMot/SynCommons.pas
$00033260
Looks like the problem is in getting the type info of enumeration types.
Next I tried to change the code that is in SynCommons.pas in the GetEnumInfo function and call the standard FPC function TypeInfo(aTypeInfo) instead of the mORMot one GetTypeInfo(aTypeInfo).
Looks like it fixed this issue, but another one appears after that and it is a problem with interfaces type info:
An unhandled exception occurred at $001F11C4:
EInterfaceResolverException: TInterfaceResolverInjected.RegisterGlobal(): TAutoLocker does not implement AutoLocker`g0CUtdJr]
SynCommons2
TA
$001F11C4 TINTERFACERESOLVERINJECTED__REGISTERGLOBALCHECK, line 58096 of C:/FreePascal/ccr/mORMot/SQLite3/mORMot.pas
$001F13B8 TINTERFACERESOLVERINJECTED__REGISTERGLOBAL, line 58114 of C:/FreePascal/ccr/mORMot/SQLite3/mORMot.pas
$00207FD0 MORMOT_$$_init$, line 62974 of C:/FreePascal/ccr/mORMot/SQLite3/mORMot.pas
$00033260
As you can see the interface IAutoLocker has its type info wrong and causes the check to fail.
Did I stumble on a bug or is there some setting or compiler directive that I've missed?
Pages: 1