Lazarus Release Candidate 2 of 2.2.0

[zed]

This is the debug information. You can get rid of it by calling "strip -s lazarus.exe" where strip is in the same folder as fpc.exe.

Thanks, that helps. But what's wrong with "Optimized IDE" profile?

[Martin_fr]

and build IDE with "Optimized IDE" profile.

Ok, that I can reproduce (well I get 1GB mem usage, but that is to much too).

The issue happens when the IDE is compiled with optimization -O2 or higher.

This is 99.9% likely being caused by a bug in FPC. https://gitlab.com/freepascal.org/fpc/source/-/commit/e9d318e7e2f772bf455a92461cd5c229e69858d8
=> I have not further debugged the issue to prove that it is indeed the particular bug, but I am pretty sure.

If you must use -O2 or higher to compile the IDE, you must add  -OoNOPEEPHOLE (which unfortunately takes away a good bit of the optimization)

The Issue is present in FPC 3.2.0 and 3.2.2.
It should be fixed in 3.2.4

It is a bug in the optimizer part of FPC.
The bug is very hard to trigger, that is only very very specific code will be compiled incorrectly. FpDebug is know to include such code.
It is unknown, if any other part of the IDE contains code that is affected.

I am not currently sure, if the old version of FpDebug (2.0.12) already had the affected code (maybe not, since there would otherwise have been problems).

Mind that the increased mem usage is just a random outcome of the bug. The bug could cause any symptoms from incorrect data/behaviour to exceptions or hard crashes.

Yes, in theory this bug can affect any project. However as I said you need to have code with just the correct number (and types) of local vars, accessed in just the correct order, with just the correct conditional (if) statements.
So far I have only seen it happen in one function in FpDebug, and only if compiled for 64 bit Windows. (but it could happen to other 64bit targets too / afaik only 64bit, but not sure on that).

[440bx]

It should be fixed in 3.2.4

Just curious, any reasonable guesstimate as to when 3.2.4 might be released ?

[zed]

Tested with "FPC 3.2.3-554-g8b21bf1cce [2021/11/14] for x86_64" (fixes_3.2 branch in fpcupdeluxe) - bug is not reproduced.

[PascalDragon]

It should be fixed in 3.2.4

Just curious, any reasonable guesstimate as to when 3.2.4 might be released ?

As you can see in this other thread, we are currently in the prepration phase. So with luck it will still be this year, though it might probably be early '22.

[trev]

Lazarus version: 2.2.0RC3
Lazarus revision: lazarus_2_2_0_RC2-33-g33d1906384
Lazarus build date: 2021/11/17
Lazarus was compiled for x86_64-darwin OS X Mountain Lion 10.8.5
Lazarus was compiled with FPC 3.2.2

All of the linker "warnings" below are prefaced by "[red exclamation mark]Error:" in the Lazarus messages window.

Code: Text  [Select][+][-]

1. Hint: (11030) Start of reading config file /etc/fpc.cfg
2. Hint: (11031) End of reading config file /etc/fpc.cfg
3. Free Pascal Compiler version 3.2.2 [2021/11/17] for x86_64
4. Copyright (c) 1993-2021 by Florian Klaempfl and others
5. (1002) Target OS: Darwin for x86_64
6. (3104) Compiling /Users/trev/tmp/project1.lpr
7. (3104) Compiling unit1.pas
8. (9009) Assembling unit1
9. (9009) Assembling project1
10. (9022) Compiling resource /Users/trev/tmp/lib/x86_64-darwin/project1.or
11. ld: warning: could not create compact unwind for _SYSTEM_$$_DUMP_STACK$TEXT$LONGINT: stack subq instruction is too different from dwarf stack size
12. ld: warning: could not create compact unwind for _SYSTEM_$$_DO_GETDIR$BYTE$RAWBYTESTRING: stack subq instruction is too different from dwarf stack size
13. ld: warning: could not create compact unwind for _UNIX_$$_READTIMEZONEFILE$SHORTSTRING: stack subq instruction is too different from dwarf stack size
14. ld: warning: could not create compact unwind for _UNIX_$$_POPEN_INTERNAL$TEXT$RAWBYTESTRING$CHAR$$LONGINT: stack subq instruction is too different from dwarf stack size
15. ld: warning: could not create compact unwind for _CLASSES$_$TPARSER_$__$$_HEXTOBINARY$TSTREAM: stack subq instruction is too different from dwarf stack size
16. ld: warning: could not create compact unwind for _SYSUTILS_$$_EXTRACTRELATIVEPATH$UNICODESTRING$UNICODESTRING$$UNICODESTRING: stack subq instruction is too different from dwarf stack size
17. ld: warning: could not create compact unwind for _SYSUTILS_$$_EXTRACTRELATIVEPATH$RAWBYTESTRING$RAWBYTESTRING$$RAWBYTESTRING: stack subq instruction is too different from dwarf stack size
18. ld: warning: could not create compact unwind for _STRUTILS_$$_FINDMATCHESBOYERMOORECASESENSITIVE$crc7515ABE9: stack subq instruction is too different from dwarf stack size
19. ld: warning: could not create compact unwind for _STRUTILS_$$_FINDMATCHESBOYERMOORECASEINSENSITIVE$crc7515ABE9: stack subq instruction is too different from dwarf stack size
20. ld: warning: could not create compact unwind for _FPREADTIFF_$$_DECOMPRESSLZW$POINTER$INT64$PBYTE$INT64: stack subq instruction is too different from dwarf stack size
21. ld: warning: could not create compact unwind for _FPREADGIF$_$TFPREADERGIF_$__$$_READSCANLINE$TSTREAM$$BOOLEAN: stack subq instruction is too different from dwarf stack size
22. (9015) Linking /Users/trev/tmp/project1
23. ld: warning: could not create compact unwind for _JCHUFF_$$_JPEG_GEN_OPTIMAL_TABLE$J_COMPRESS_PTR$JHUFF_TBL_PTR$TLONGTABLE: stack subq instruction is too different from dwarf stack size
24. ld: warning: could not create compact unwind for _JCMASTER_$$_VALIDATE_SCRIPT$J_COMPRESS_PTR: stack subq instruction is too different from dwarf stack size
25. ld: warning: could not create compact unwind for _PROCESS$_$TPROCESS_$__$$_READINPUTSTREAM$TINPUTPIPESTREAM$TSTREAM$LONGINT$$BOOLEAN: stack subq instruction is too different from dwarf stack size
26. (1008) 51 lines compiled, 1.6 sec
27. (1022) 2 hint(s) issued

This was simply compiling a blank form. It does run despite the scary error messages

[Gilles HEM]

Hello,

in one of my components, I use the StringCase method implemented in lazarus until version 2.0.12.

Code: Pascal  [Select][+][-]

1. // case..of utility functions
2. function StringCase(const AString: String; const ACase: array of String {; const AIgnoreCase = False, APartial = false: Boolean}): Integer; overload;
3. function StringCase(const AString: String; const ACase: array of String; const AIgnoreCase, APartial: Boolean): Integer; overload;

In Lazarus 2.2.0RC1 & 2 :

• It does not appear that the two methods were moved to another unit.
• Nor does it appear to have been replaced by any other method

So I reimplemented it as it exists in Lazarus 2.0.12 directly in the lclproc.pas file of Lazarus 2.2.0RC1 then 2.2.0.RC2.
Is there any better way ?
Regards. Gilles

[El Salvador]

I found in lazstringutils unit: https://gitlab.com/freepascal.org/lazarus/lazarus/-/blob/fixes_2_2/components/lazutils/lazstringutils.pas#L103

[Gilles HEM]

Hello El Salvador,

thanks for your help.
I didn't think to look for Stringcase in the components folder. I limited my research to the lcl directory.
I added lazstringutils to the uses of my component and remove the code reimplanted in lclproc. It works well.

Regards. Gilles

[PascalDragon]

I found in lazstringutils unit: https://gitlab.com/freepascal.org/lazarus/lazarus/-/blob/fixes_2_2/components/lazutils/lazstringutils.pas#L103

That some refactoring went on there should probably be mentioned in the Release Notes.

[zed]

Lazarus shows message "Compiler ... does not support target x86_64-win64" but compiler supports it and if I ignore this message and run build project it compiles win64 binary and works fine.

My steps:
1. Using fpcupdelux x32 install fpc 3.2.2 from Basic tab (it will install win32 compiler)
2. From tab Cross install cross-compiler for win64
3. Start Lazarus, configure with fpc binaries (in my case D:\apps\fpc\stable\fpc\bin\i386-win32\fpc.exe) and src (D:\apps\fpc\stable\fpcsrc)
4. Build win64 target - error message showed.

P.S. If I use fpcupdeluxe x64, install fpc win64 and then win32 cross-compiler, all works fine, but this scenario is "ill-advised" and not recommended by fpc/fpcupdeluxe developers (according to this and this).

[prof7bit]

I don't get why they need "lazarus" or "release" (or anything besides the version number) at all. This is just redundant and does not carry any information at all. If the convention is to tag the release then the fact that the tag is a release is inherent.

If we do add other tags, for whatever other reasons in future, then we need to distinguish.

Already, not every tag is a tag for a release.
Tags starting with main and t-fixes mark the first commit after branch diverge.
But those tags, also look like version numbers. So they need to be distinguished from release tags.

Those branch start tags start with "t-". My reasoning was that every tag that looks like a version number and does not have a "t-" would then by definition be a release tag. An alternative (if all these special tags should have prefixes to make them stand out) would be to prefix them "r-", this would be more consistent and make much more sense that calling them "lazarus" because literally everything inside this repository is Lazarus.

BTW: I always wondered why these branch start tags are called "t-", I personally would have called them "b-" (branch), but this is not a real problem.

[AFFRIZA 亜風実]

I can't comment a line using Ctrl + / in KDE Plasma (Neon 20.04). Anyone experienced this?  I tested KDevelop, it works normal, so it should not my keyboard.

(Actually I accidentally installed RC3 from fpcupdeluxe, should I downgrade?) 

[JuhaManninen]

I can't comment a line using Ctrl + / in KDE Plasma (Neon 20.04). Anyone experienced this?  I tested KDevelop, it works normal, so it should not my keyboard.
(Actually I accidentally installed RC3 from fpcupdeluxe, should I downgrade?) 

This is Lazarus, not KDevelop. Try Ctrl-Shift-V and Ctrl-Shift-U. See Source menu.
If you want to discuss the selections more, please open a new thread. This thread is about the coming 2.2 release.
RC3 from fixes_2_2 branch is good.

[dsiders]

I can't comment a line using Ctrl + / in KDE Plasma (Neon 20.04). Anyone experienced this?  I tested KDevelop, it works normal, so it should not my keyboard.
(Actually I accidentally installed RC3 from fpcupdeluxe, should I downgrade?) 

This is Lazarus, not KDevelop. Try Ctrl-Shift-V and Ctrl-Shift-U. See Source menu.
If you want to discuss the selections more, please open a new thread. This thread is about the coming 2.2 release.
RC3 from fixes_2_2 branch is good.

If you check Tools > Options > Editor > Key Mappings > Text Selection commands:

Toggle Comment in Selection is mapped to Ctrl + /.

Works as expected on Windows.