Latest mORMot.pas does not compile under latest FPC.

ComingNine · 2018-09-12 05:31:51

Latest mORMot.pas does not compile using latest FPC for both i386-win32 and x86_64-linux. The line and msg shown are below.

Line 56264:             ParamName := @VMP^.Name;  
mORMot.pas(56264,30) Error: Variable identifier expected

The reason is in FPC 3.3.1-r39711 (installed using fpcupdeluxe), Name becomes a property. NamePtr should be used.

ParamName := VMP^.NamePtr;

PS: It seems that anonymous cannot create ticket now ? There is no create ticket on the tickets link.

Last edited by ComingNine (2018-09-12 08:09:31)

ab · 2018-09-12 18:09:50

Dup question.

Search the forum first.

ComingNine · 2018-09-16 04:12:46

Just curious: do you plan not to fix it ?

Leslie7 · 2018-09-18 06:45:55

ComingNine wrote:

Just curious: do you plan not to fix it ?

I am waiting for this too. AB gives the best support to an opensource project I have ever seen. Usually fixes come very fast. If not there is reason. Maybe his main job requires more of his time now ... I think we better trust him on task scheduling.

Also this could be an issue which needs to be fixed by the FPC team.

Last edited by Leslie7 (2018-09-18 06:47:04)

Leslie7 · 2018-09-18 09:23:48

The problem is that FPC trunk - at least in this case. maybe more generally - does not handle the address operator for a record property with a getter.

This solves the problem and makes sense performance-wise, but directly accessing the underlying pointer may violate a design principle:

ParamName := VMP^.NamePtr;

Last edited by Leslie7 (2018-09-18 11:46:34)

JD · 2018-09-18 11:50:47

I had the same problem. I keep two versions of Lazarus: NewPascal (with FPC 3.1.1) and Lazarus 1.8.4/FPC 3.0.4 stable on my system. This was OK for me until the Lazarus 1.8.4/FPC 3.0.4 could no longer handle the new TypeInfo changes in the latest version of mORMot (SynFPCTypInfo.pas).

Luckily, I saw on the Lazarus forum a new package Lazarus 1.9/FPC 3.2.0 Beta.

http://forum.lazarus-ide.org/index.php/ … ajilg0#new

https://sourceforge.net/projects/lazaru … ndow%2032/
https://sourceforge.net/projects/lazaru … ndow%2064/

I installed this and it compiled the latest mORMot releases flawlessly; I guess because the FPC compiler is more recent and so has the RTTI changes that NewPascal was created to handle. It also compiled the old code I was keeping Lazarus 1.8.4/FPC 3.0.4 around for.

So it looks like I may move ALL my projects to Lazarus 1.9/FPC 3.2.0 Beta and get rid of my existing NewPascal & Lazarus 1.8.4/FPC 3.0.4 combo.

I encourage you to try it. It may be the solution to your problem.

I can confirm that the line

Line 56267:             ParamName := @VMP^.Name;

is compiled properly

Cheers,

JD

Last edited by JD (2018-09-18 11:56:26)

pvn0 · 2018-09-20 08:44:57

Do you guys use fpcupdeluxe? I have never been able to install anything with that, I always do it manually.

JD · 2018-09-20 08:57:00

pvn0 wrote:

Do you guys use fpcupdeluxe? I have never been able to install anything with that, I always do it manually.

I use fpcupdeluxe to test trunk builds and sometimes to install NewPascal. I did not use it in my most recent install because FPC trunk is now 3.3.1 and some have said in this thread that it does not compile the latest mORMot.

That is why I chose to install Lazarus 1.9/FPC 3.2.0 Beta instead which is more recent than NewPascal and does not seem to have the problem associated with FPC trunk.

JD

Last edited by JD (2018-09-20 09:04:18)

edwinsn · 2018-09-20 15:51:33

Update: With Lazarus/FPC trunk installed by fpcupdeluxe just now (Lazarus 2.1.0 r59094, FPC 3.3.1), the latest mORMot can be compiled successfully, even cross-compile for linux64!

damiand · 2018-09-21 15:01:45

Not in my case, unfortunately. Using fpcupdeluxe with latest Lazarus/FPC trunk (2.1.0/3.3.1 SVN 59094) on Linux Lite 3.8 (based on Ubuntu), the compilation stops in line 56267 of mormot.pas:

ParamName := @VMP^.Name;

with error message:

mORMot.pas(56267,31) Error: Variable identifier expected

I presume that the solution proposed by Leslie7 in post #5 above, as well as in this topic also:

https://synopse.info/forum/viewtopic.php?id=4694

is recommended, isn't it?

Thanks.

Last edited by damiand (2018-09-21 15:12:00)

mpv · 2018-09-22 09:27:02

Every new commit to the FPC trunk can broke our code (this is developer trunk). Unfortunately there is no stable FPC version what support all features required by mORMot (or I don't know it).

So, in my project a freeze FPC & Lazarus revision - currently to FPC 39623 & Lazarus 58733. I can confirm this combination work for both Win64 & Lin64 with cross-compiling back and forward.

miab3 · 2018-09-22 14:56:43

In fpc 3.3.1 does not work:

ParamName := @VMP^.Name;

neither this:

ParamName := VMP^.Name;

Michal

Last edited by miab3 (2018-09-22 14:57:26)

Leslie7 · 2018-09-22 21:19:52

miab3,

Until FPC is fixed or there is an official mORMot workaround this solves the problem:

ParamName := VMP^.NamePtr;

Leslie7 · 2018-09-25 17:04:18

pvn0 wrote:

Do you guys use fpcupdeluxe? I have never been able to install anything with that, I always do it manually.

You can check out the source and run it from the IDE to see where it goes wrong for you:

https://github.com/newpascal/fpcupdeluxe

ab · 2018-09-29 08:14:11

Try https://synopse.info/fossil/info/b3001e4a56

edwinsn · 2018-09-30 06:03:08

I confirm the compilation issue's fixed.

Leslie7 · 2018-09-30 08:52:14

ab wrote:

Try https://synopse.info/fossil/info/b3001e4a56

AB,

I am curious: since NamePtr is public anyway it would seem obvious to use it directly. What is the point for going through the string property and it's getter to get to a pointer at the end which is already available? FPC ShortString is not reference counted so the getter returns a new string with a different pointer. Where will the new string be freed? It seems like a potential memory leak. Or if this is intentional and the new string is freed somewhere properly then when VER3_1 is not defined it will free VMP^.NamePtr^ which is likely to cause problems.

Last edited by Leslie7 (2018-10-01 11:52:22)

Leslie7 · 2018-10-11 07:17:23

AB,

I think this is worth attention.

ab · 2018-10-11 10:11:31

"memory leak" / "free NamePtr^"?
IIRC, this is a shortstring, directly pointing to the executable binary RTTI.

Leslie7 · 2018-10-11 16:32:07

ab wrote:

"memory leak" / "free NamePtr^"?

That is the gist of it. Either way the the fix is inconsistent, returns different pointers depending on the compiler directive.

Last edited by Leslie7 (2018-10-11 16:33:20)

ab · 2018-10-11 21:14:42

A pointer to a shortstring stored in the code segment of the executable making a memory leak?

Leslie7 · 2018-10-12 07:39:52

When VER3_1 is defined the getter for the Name property creates a NEW string and the pointer to this string is used from there, not the original pointer. The question is what happens to this new string, will it ever be freed?

ab · 2018-10-12 10:30:04

When VER3_1 is defined, the Name property is not a getter but a field:

      TVmtMethodParam =
...
        Name: ShortString;

For newest versions (3.2 branch), including new trunk, it uses NamePtr safely.
https://github.com/graemeg/freepascal/b … fo.pp#L337

This was the whole point of Michalis patch.
Or perhaps the VER3_1 is not what we expect?

michalis · 2018-10-15 19:54:46

See the description of my pull request on https://github.com/synopse/mORMot/pull/133 .

FPC revision 39684 (during FPC 3.3.1 development) changed the way you have to access this information. In FPC revision < 39684, you must use "@VMP^.Name". In FPC revision >= 39684 you must use "VMP^.NamePtr".

The FPC revision 39684 happened during the FPC 3.3.1 development.

The patch from https://github.com/synopse/mORMot/pull/133 assumes that:

- You either use FPC 3.1.1.
- Or you use FPC 3.3.1 with revision >= 39684.

The original poster uses FPC 3.3.1, revision 39711. This should be supported. The VER3_1 should not be defined, and the correct approach ("VMP^.NamePtr") should be used.

(Note: I removed my earlier answer, I made a mistake there This answer is correct.)

ab · 2018-10-16 07:04:07

Great!

Compiling and running:

begin
  {$ifdef VER3_1} Writeln('This is FPC 3.1.x'); {$endif}
  {$ifdef VER3_3} Writeln('This is FPC 3.3.x'); {$endif}
end.

with FPC 3.3.1:

$ fpc a.pas 
Free Pascal Compiler version 3.3.1-r39838 [2018/09/28] for x86_64
Copyright (c) 1993-2018 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling a.pas
Linking a
4 lines compiled, 0.7 sec
$ ./a
This is FPC 3.3.x

So the patch sounds just fine, and I don't understand what Leslie7 complained about.

mORMot Open Source

#1 2018-09-12 05:31:51

Latest mORMot.pas does not compile under latest FPC.

#2 2018-09-12 18:09:50

Re: Latest mORMot.pas does not compile under latest FPC.

#3 2018-09-16 04:12:46

Re: Latest mORMot.pas does not compile under latest FPC.

#4 2018-09-18 06:45:55

Re: Latest mORMot.pas does not compile under latest FPC.

#5 2018-09-18 09:23:48

Re: Latest mORMot.pas does not compile under latest FPC.

#6 2018-09-18 11:50:47

Re: Latest mORMot.pas does not compile under latest FPC.

#7 2018-09-20 08:44:57

Re: Latest mORMot.pas does not compile under latest FPC.

#8 2018-09-20 08:57:00

Re: Latest mORMot.pas does not compile under latest FPC.

#9 2018-09-20 15:51:33

Re: Latest mORMot.pas does not compile under latest FPC.

#10 2018-09-21 15:01:45

Re: Latest mORMot.pas does not compile under latest FPC.

#11 2018-09-22 09:27:02

Re: Latest mORMot.pas does not compile under latest FPC.

#12 2018-09-22 14:56:43

Re: Latest mORMot.pas does not compile under latest FPC.

#13 2018-09-22 21:19:52

Re: Latest mORMot.pas does not compile under latest FPC.

#14 2018-09-25 17:04:18

Re: Latest mORMot.pas does not compile under latest FPC.

#15 2018-09-29 08:14:11

Re: Latest mORMot.pas does not compile under latest FPC.

#16 2018-09-30 06:03:08

Re: Latest mORMot.pas does not compile under latest FPC.

#17 2018-09-30 08:52:14

Re: Latest mORMot.pas does not compile under latest FPC.

#18 2018-10-11 07:17:23

Re: Latest mORMot.pas does not compile under latest FPC.

#19 2018-10-11 10:11:31

Re: Latest mORMot.pas does not compile under latest FPC.

#20 2018-10-11 16:32:07

Re: Latest mORMot.pas does not compile under latest FPC.

#21 2018-10-11 21:14:42

Re: Latest mORMot.pas does not compile under latest FPC.

#22 2018-10-12 07:39:52

Re: Latest mORMot.pas does not compile under latest FPC.

#23 2018-10-12 10:30:04

Re: Latest mORMot.pas does not compile under latest FPC.

#24 2018-10-15 19:54:46

Re: Latest mORMot.pas does not compile under latest FPC.

#25 2018-10-16 07:04:07

Re: Latest mORMot.pas does not compile under latest FPC.

Board footer