Lazarus
Announcements => Lazarus => Topic started by: Martin_fr on June 21, 2021, 12:36:50 pm
-
The Lazarus team is glad to announce that:
The release of Lazarus 2.2.0
with FPC 3.2.2
has been scheduled for around
July/August 2021
(fixes_2_2 branch has been created)
A first release candidate will be made available around
June/July 2021
The previous release was Lazarus 2.0.12 which was built with FPC 3.2.0.
The minimum supported version of FPC for this release will be FPC 3.2.0.
Due to some issues with optimized (-O2 and higher) code generated
by FPC 3.2.0 and 3.2.2, an extended support for compilation with FPC 3.0.4
has been added for the LCL.
The Lazarus IDE should be build with -O1. Anyone wishing to use
higher optimization may need to add -OoNOPEEPHOLE to avoid
crashes of the IDE.
Here is the list of new features for Lazarus 2.2.0:
https://wiki.lazarus.freepascal.org/Lazarus_2.2.0_release_notes
We would invite everyone to provide their feedback to help us improve this upcoming release.
Please let as know in particular:
- Any regressions that happened since the last release.
- Other urgent matters, you believe we should know before the release.
The intended minimum requirements for the release will be:
Windows:
2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit.
FreeBSD/Linux:
gtk 2.8 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit.
Mac OS X:
10.5 to 10.12; Carbon (32bit), Cocoa (64bit, beta), qt and qt5 (32 or 64bit).
-
Out of curiosity: why is this in the Free Pascal announcements instead of the Lazarus ones? :-X
-
Here is the list of new features for Lazarus 2.2.0:
https://wiki.lazarus.freepascal.org/Lazarus_2.2.0_release_notes
I miss the UItypes deprecated status? Or was the branch to 2.2.0 already done before that (few weeks old) change?
-
Out of curiosity: why is this in the Free Pascal announcements instead of the Lazarus ones? :-X
Sorry my fault, amended.
-
I have a question concerning the new release and compatibility:
Will there be a native apple silicon (M1) version available for download with the release of Lazarus 2.2?
If not, can you give a brief outlook on when we can expect a (stable) version of Lazarus on apple silicon for download?
Thanks!
-
I have a question concerning the new release and compatibility:
Will there be a native apple silicon (M1) version available for download with the release of Lazarus 2.2?
If not, can you give a brief outlook on when we can expect a (stable) version of Lazarus on apple silicon for download?
Thanks!
This is still being looked into. I hope we can make a statement on that, once the first RCs have been build.
What I do know, is that there is currently no progress on the debugger for M1.
While I can not test it myself, the bare lldb (without fpdebug) might work. But the available data will be rather poor.
There is currently no date on updates for the debugger
-
@Martin_fr RC1 won't build for Qt widgetset without r65248 (which is added to Lazarus 2.2 fixes branch merges https://wiki.freepascal.org/Lazarus_2.2_fixes_branch#Submitted_by_developer_.2F_committer.2C_tested.2C_waiting_to_be_merged )
-
Will there be a native apple silicon (M1) version available for download with the release of Lazarus 2.2?
I don't have a M1, so I can't test and build there. Maybe there is a volunteer?
-
Great news! :)
-
Here is the list of new features for Lazarus 2.2.0:
https://wiki.lazarus.freepascal.org/Lazarus_2.2.0_release_notes
I miss the UItypes deprecated status? Or was the branch to 2.2.0 already done before that (few weeks old) change?
Afaik it should be part of it. Probably just someone needs to put it on the wiki....
-
I miss the UItypes deprecated status? Or was the branch to 2.2.0 already done before that (few weeks old) change?
Afaik it should be part of it. Probably just someone needs to put it on the wiki....
It's there already, in Changes affecting compatibility: LazUtils (https://wiki.lazarus.freepascal.org/Lazarus_2.2.0_release_notes#LazUtils):UITypes unit is deprecated in favor of System.UITypes, which is available in FPC 3.2.0 and up. [etc]
Or did you mean something else?
-
Is Windows 2000 still supported? The reason I ask this is that I see that the latest svn trunk build has a dependency on DebugBreakProcess which is not available on Windows 2000.
-
Is Windows 2000 still supported?
No offense, but I hope they drop even Windows 7.
There's absolutely no need to use the newest IDE on old SOs when you can still use old versions of Lazarus.
-
Is Windows 2000 still supported? The reason I ask this is that I see that the latest svn trunk build has a dependency on DebugBreakProcess which is not available on Windows 2000.
Afaik FPC is not regularly tested with win 2000/XP either.
-
Is Windows 2000 still supported?
No offense, but I hope they drop even Windows 7.
There's absolutely no need to use the newest IDE on old SOs when you can still use old versions of Lazarus.
Yes, there is, because newer versions of the IDE provide newer features. An attitude like yours is not something we support.
Will there be a native apple silicon (M1) version available for download with the release of Lazarus 2.2?
I don't have a M1, so I can't test and build there. Maybe there is a volunteer?
Maybe trev can help since he's doing nightly builds for that platform anyway?
-
No offense, but I hope they drop even Windows 7.
There's absolutely no need to use the newest IDE on old SOs when you can still use old versions of Lazarus.
No offense but did you checked how much people uses Windows 7? Dropping Win7 support can be VERY bad decision. Especially if we will remember what even DOS still supported by compiler.
-
No offense, but I hope they drop even Windows 7.
There's absolutely no need to use the newest IDE on old SOs when you can still use old versions of Lazarus.
No offense but did you checked how much people uses Windows 7? Dropping Win7 support can be VERY bad decision. Especially if we will remember what even DOS still supported by compiler.
Actually, when i said Win7, it was an hyperbole.
But, in fact, Win7 will no longer receives updates.
Even Embarcadero already dropped support for Win7 few years ago.
But I know that a lot still use Win7 today, but no one uses 3.11.
The list of new features are very good!
Some things they do that even Delphi can't, like the TCheckGroup, and Mask support for hexadecimal and binary.
-
I think there is a misunderstanding:
You have to differentiate between your dev-machine and a possible target-machine.
I agree that it doesn't make sense to install the newest IDE on Win2K, but developing on a Win7/10-machine, and the final program being able to run on a Win2K/XP-machine are two different things.
EDIT: Except if you're talking about the LCL supporting the WidgetSet used on Win2K, which should still be "win32"
-
We got no feedback on the RCs, so I assume it all works fine :-)
-
We got no feedback on the RCs, so I assume it all works fine :-)
Isn't a little early? I took this to be more of a heads-up to prepare to start RC-testing when there is an RC available, since Martin didn't say there was one already: he just noted what the new release is about. Or that's how I took it; I might be absolutely wrong :-[
-
So, I need to point out that fixes_2_2 (downloaded this morning) has this bug, https://bugs.freepascal.org/view.php?id=38922
It affects windows developers who are using HiPDI screens and making binaries that will be used on normal screens OR developers using normal DPI and the binaries may possibly be used on a HiDPI system. Important to note that the developer testing the code on his/her working system will not pickup this problem !
What happens is that forms that are not shown at startup, are having their FormShow event called during startup. The form is not actually shown, I guess its not ready at that stage. So, in some cases that does not matter but in other cases, code in the FormShow method depends other things having happened and a crash results. Personally, I would greatly prefer to have FormShow called when the form is being shown !
As many median priced laptops these days have hiDPI screens, we should see quite a lot systems being affected.
Very easy to demonstrate, on (eg) a normal DPI screen system, make the usual default main form, add a second form, Unit2 and in its OnShow event, put "showmessage('Unit 2 FormShow'); "
Take the binary to a HiDPI system and run it. Or take the project there and compile and run it (being careful not to make unit2.lfm rewrite).
The difference in DPI relates to a line in the lfm file, DesignTimePPI = 144
The bug report identifies the revision that the problem first appeared in trunk and also mentions a later fix that has subsequently been reversed .......
Davo
-
Is Windows 2000 still supported?
I still have a VM with Win2000, pulled myself a Laz-trunk and built it on the basis of FPC3.2.2. "make bigide" resulted in an IDE which did not start. But "make all" made it work. I removed all the packages that I do not need, and then added TAChart, TurboPower, DateTimeCtrls, and DbfLaz - still working. Compiled and ran some of my applications, they all work.
So the message is: there is a good chance that you may be able to build your application with Laz 2.2/FPC3.2.2 on Win 2000. Of course - no guarantee...
-
Is Windows 2000 still supported? The reason I ask this is that I see that the latest svn trunk build has a dependency on DebugBreakProcess which is not available on Windows 2000.
I don't have W2000 for testing. But if that is the reference in fpdebug, I think that can be dynamically loaded. I have to look into this.
Strange though. I thought 2.0.x had fpdebug included too. So that should have had the same issue?
-
Will there be a native apple silicon (M1) version available for download with the release of Lazarus 2.2?
I don't have a M1, so I can't test and build there. Maybe there is a volunteer?
Maybe trev can help since he's doing nightly builds for that platform anyway?
There's a small complication: the M1 operating system (Big Sur) will not execute unsigned code. The code can be signed with an ad hoc signature (ie without an Apple developer Certificate) but it is only valid for the machine on which it was signed. For those who want it to be "out of the box", every executable in the Lazarus distribution would need to be signed with an Apple Developer Certificate. Whether Lazarus recompilations would be ok, is unknown. The Apple linker will sign anything linked on an M1 with an ad hoc signature by default which may be ok.
The executables in the daily snapshots I do, need to be ad hoc signed by the enduser which I don't see as a big issue because anyone installing daily development (trunk) snapshot versions should possess the knowledge to do so (or at least be able to follow the explanation to do so which I added to the Wiki and link to).
I've been meaning to add signing and possibly notarizing of the executables with my (personal) Apple Developer Certificate, but as I haven't had any feedback since automating the daily build processes as launchctl daemons, I didn't pursue it.
Really, I think the easiest thing to do may be to simply provide a script to build Lazarus from the release source on M1 machines. It takes about 9 minutes on my base model M1 Mac mini including syncing the source repository.
-
Really, I think the easiest thing to do may be to simply provide a script to build Lazarus from the release source on M1 machines. It takes about 9 minutes on my base model M1 Mac mini including syncing the source repository.
Another way might be creating a simple shell script that checks if there is a signature on the Lazarus bundle and ad-hoc code-signs it if not. Then launches the Lazarus executable.
This script would be used to start Lazarus by user.
-
We got no feedback on the RCs, so I assume it all works fine :-)
Isn't a little early? I took this to be more of a heads-up to prepare to start RC-testing when there is an RC available, since Martin didn't say there was one already: he just noted what the new release is about. Or that's how I took it; I might be absolutely wrong :-[
I'm talking about FPC 3.2.2, see e.g. the RC1 issues page: https://wiki.freepascal.org/Issues_3.2.2 No mention of 2k or XP. Conclusion: nobody cares.
-
We got no feedback on the RCs, so I assume it all works fine :-)
Isn't a little early? I took this to be more of a heads-up to prepare to start RC-testing when there is an RC available, since Martin didn't say there was one already: he just noted what the new release is about. Or that's how I took it; I might be absolutely wrong :-[
I'm talking about FPC 3.2.2, see e.g. the RC1 issues page: https://wiki.freepascal.org/Issues_3.2.2 No mention of 2k or XP. Conclusion: nobody cares.
Well, considering that no one found the problem with variants mentioned here (https://lists.freepascal.org/pipermail/fpc-devel/2021-May/043877.html) during the RC phase, but only after the release, I'd have this conclusion: nobody cares about RCs. :P
-
Well, considering that no one found the problem with variants mentioned here (https://lists.freepascal.org/pipermail/fpc-devel/2021-May/043877.html) during the RC phase, but only after the release, I'd have this conclusion: nobody cares about RCs. :P
or perhaps no one cares about variants ? In a strongly typed language, maybe that makes sense ? ;)
Davo
EDIT: I spent a good part of today getting a working Fixes on Windows to test for the bug I mentioned above, yep, I care about RCs !
-
Is Windows 2000 still supported? The reason I ask this is that I see that the latest svn trunk build has a dependency on DebugBreakProcess which is not available on Windows 2000.
But if that is the reference in fpdebug, I think that can be dynamically loaded. I have to look into this.
ok, the reference in fpdebug is now dynamically loaded.
If it fails an alternative had already been in place. So fpdebug may (or may not) work on win 2000. (not a goal to support this part, but if it does, well good)
-
Is Windows 2000 still supported? The reason I ask this is that I see that the latest svn trunk build has a dependency on DebugBreakProcess which is not available on Windows 2000.
But if that is the reference in fpdebug, I think that can be dynamically loaded. I have to look into this.
ok, the reference in fpdebug is now dynamically loaded.
If it fails an alternative had already been in place. So fpdebug may (or may not) work on win 2000. (not a goal to support this part, but if it does, well good)
I can verify the latest build runs on W2k. But debugging seems slow - F7/F8 takes about 20% CPU usage.
-
I can verify the latest build runs on W2k. But debugging seems slow - F7/F8 takes about 20% CPU usage.
While it is not likely that much will be done on debugging, just for win2k, out of interest:
gdb based or fpdebug?
Also, if fpdebug: it is not related to that latest change. that code is not called by stepping.
Patches can be accepted, for that, but depending on complexity may or may not be merged.
EDIT:
Btw, how much mem is used on your system?
-
BTW: win2K is the mother of WinXP. The latter is no longer supported.
When you still need Win2K development, freeze the working toolchain,
You can not always keep up with legacy platforms that are no longer supported by the platform distributor. It is even a bad idea.
You will miss features of the recent toolchains, but at least you can keep it running.
-
Really, I think the easiest thing to do may be to simply provide a script to build Lazarus from the release source on M1 machines. It takes about 9 minutes on my base model M1 Mac mini including syncing the source repository.
The idea of just providing a script for apple silicon users that would download and install (--> compile) Lazarus all on its own sounds really good to me.
Would it be possible for you to create such a script and (maybe) to provide a link to it in the lazarus article on installing lazarus on macOS?
I think that the combination of the script and the link to it in installment articles would help a lot of users out!
-
A fink package might be a fix as well, since it builds from sources. However, I have to work on that. Similar for macport.
-
I can verify the latest build runs on W2k. But debugging seems slow - F7/F8 takes about 20% CPU usage.
While it is not likely that much will be done on debugging, just for win2k, out of interest:
gdb based or fpdebug?
Also, if fpdebug: it is not related to that latest change. that code is not called by stepping.
Patches can be accepted, for that, but depending on complexity may or may not be merged.
EDIT:
Btw, how much mem is used on your system?
I don't know. I am just a casual user of Lazarus. I use F9 to debug.
-
gdb based or fpdebug?
EDIT:
Btw, how much mem is used on your system?
I don't know. I am just a casual user of Lazarus. I use F9 to debug.
Well the mem usage is in the task manager: run taskmgr.exe
The debugger type: Tools > Options > Debugger > debugger backend
Look in the top tool-bar, it should either have something with fpdebug, or with gdb (or gnu)
The reason I asked is, that the default changed, and it depends on if you had an earlier install, and that the new default actually worked.
You can also (in the top toolbar) toggle between the two, and see if one is better that the other.
-
gdb based or fpdebug?
EDIT:
Btw, how much mem is used on your system?
I don't know. I am just a casual user of Lazarus. I use F9 to debug.
Well the mem usage is in the task manager: run taskmgr.exe
The debugger type: Tools > Options > Debugger > debugger backend
Look in the top tool-bar, it should either have something with fpdebug, or with gdb (or gnu)
The reason I asked is, that the default changed, and it depends on if you had an earlier install, and that the new default actually worked.
You can also (in the top toolbar) toggle between the two, and see if one is better that the other.
Memory is not a problem at all. Official 2.0.12 release works perfectly on W2k.
I have only one debugger (gdb) so that means 2.2RC may have a problem with gdb debugging (with -g flag).
I also tried fpdebug and found that it does not step into components source code as gdb. For example, pressing F7 on self.Caption := 'any' does not automatically go to control.inc.
-
Memory is not a problem at all. Official 2.0.12 release works perfectly on W2k.
I have only one debugger (gdb) so that means 2.2RC may have a problem with gdb debugging (with -g flag).
I also tried fpdebug and found that it does not step into components source code as gdb. For example, pressing F7 on self.Caption := 'any' does not automatically go to control.inc.
** Gdb: There a quite a few things that may be....
- As you build trunk yourself, you did not download a new gdb version => so you use the same version as before (no change here).
- There have been changes on the IDE site. Dealing with SEH exceptions, and other stuff. I don't know how much of an impact they have.
- Compare the filesize of the project.exe that you are debugging => if it has changed massively between 2.0.12 and trunk, then maybe some packages had debug info added, that did not have it before. But that would only make a diff, if memory was low..
- 2.2 Will come with a diff gdb version.
https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/GDB%209.2%20-%20Modified%20for%20unicode/
https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032%20bits/Alternative%20GDB/GDB%209.2%20%28cygwin%29/
I do not know, if that will be good for older windows, but you can download different gdbs from our sourceforge page.
** FpDebug
You are using 32 bits?
Then -g may still mean "stabs" (see entries under "debug info type" in project options.
Fpdebug only supports dwarf (you will have noted the pop up).
That pop up only changed your project.
It did not affect the packages.
If you build packages with -gw then that will work.
=> Most packages use the "IDE build options" => go to Tools > Configure build lazarus => and add the option there (Press "Save" to exit, no need to build)
There are different dwarf versions.
- If you plan to also use gdb or go back to gdb => stick to version 2 (or later change it back). gdb has some extra crashes with dwarf version 3
In that case use the options
-gw -godwarfsets
- If you decide to stick with fpdebug (or change options as you change debugger)
Use
-gw3
dwarf 3 gives you upper/lowercase names => nice.
You can mix dwarf 2 and 3. Eg compile packages with dwarf 2, and the project with dwarf 3 (for fpdebug)
If FpDebug works for you => I do recommend it.
-
... getting back to the release candidate.
On the Mac, fixes_2_2 builds, by default a 64bit IDE etc. Good. But when you first start Lazarus, without an existing configuration, it first finds and suggests the ppc386 compiler. And says its OK. I don't think so.
Secondly, the same initial config assumes we are going to use gdb, I thought lldb was the preferred debugger on MacOS ?
In my case the scanning for FPC source seemed to not work too. I waited ten minutes before I stopped and entered the location manually. It appeared to be starting in the right place, /usr/local/share/fpcsrc and that dir on my system contained only an old install of 3.0.4 and the 3.2.0 so not a lot of searching needed. but my Mac is pretty old ...
Davo
-
Even Embarcadero already dropped support for Win7 few years ago.
This is incorrect.
Applications of the latest version of Delphi can, according to the documentation (http://docwiki.embarcadero.com/RADStudio/Sydney/en/Supported_Target_Platforms), run on Windows 10, Windows 8.1, Windows 7 (SP1+), Windows Server 2019, Windows Server 2016, and Windows Server 2012 R2.
Moreover, the IDE itself also works on the same platforms.
-
...
The Lazarus IDE should be build with -O1. Anyone wishing to use
higher optimization may need to add -OoNOPEEPHOLE to avoid
crashes of the IDE.
...
That's a bit disturbing. Has anyone identified any particular crashes? I thought I had ironed those out.
-
Just a side note, I still use a bit outdated FPC 3.2.1 fixes tree and my large product works flawless on Mac (Intel and M1) compiled with -O2. I also compiled IDE with default settings - no problem.
-
...
The Lazarus IDE should be build with -O1. Anyone wishing to use
higher optimization may need to add -OoNOPEEPHOLE to avoid
crashes of the IDE.
...
That's a bit disturbing. Has anyone identified any particular crashes? I thought I had ironed those out.
Unfortunately not.
https://lists.freepascal.org/pipermail/fpc-devel/2021-June/043884.html
-
Hmmm, nuts. I've got to find the patch that fixes it in 3.3.1.
-
...
...
Is it not this? https://bugs.freepascal.org/view.php?id=37305
-
Its hard to say. I can't build and test fpc for every un-merged bug... (if that one is indeed not merged)
In components/Lazdebuggers/lazDebuggerFp is a testcase. If compiled with -O2 (win 64) it crashes.
Feel free to
1) test if you can reproduce the crash
2) test any fpc build you want