FPC 3.2.4-rc1 available lazarus / 60-Free Pascal ---------------------------------------------------------------------- PascalDragon · 2025-06-23 13:29 As some might have noticed, we have placed the first release candidate of the Free Pascal Compiler version 3.2.4 on our download servers already for some time. You can help improve the upcoming 3.2.4 release by downloading and testing this release. If you want you can report what you have done here or in the maillist. Changes that may break backwards compatibility will be documented here. Downloads are available here. The evaluation time frame for this release is at least two weeks, so bug reports within that period will be looked at before the final release is branched. Enjoy! The Free Pascal Compiler Team Release Notes:                             Free Pascal Compiler                                 Version 3.2.4 Free Pascal 3.2.4 is a minor release of the 3.2.x fixes branch. As such, it contains mostly fixes of bugs discovered in the previous version, plus some updates for included packages. There are currently no known changes which might result in incompatibility with the previous version 3.2.2. The main highlights of this version: large number of issue and bug fixesFPC development switched to git, all tools adapted accordinglyfixes to avoid year 2038 problemupdated translations of compiler messagesIssues with newer glibc fixed Platforms: Support for new AVR targets: megaAVR 0 and tinyAVR 0/1FreeBSD 12 supportDarwin: made -gl working Utilities: FPDoc: markdown supportfpcres: several improvements Packages: fcl-image improved, e.g. resolution support and orientation flag supportfcl-base: thread pool supportfcl-pdf: pdf readervcl-compat significantly improved ---------------------------------------------------------------------- jwdietrich · 2025-06-23 20:38 Great! Thanks to the whole team! ---------------------------------------------------------------------- dbannon · 2025-06-24 00:18 Great progress PD, thanks !  A couple of comments - The Testers page seems to have its content duplicated. There is not a link to the download page from the Testers page The download  page has all its text in a very finely stroked font and, critical information is in pale blue on a grey background, on at least one of my monitors almost impossible to read. But putting that aside, progress ! Davo ---------------------------------------------------------------------- dbannon · 2025-06-24 04:57 Its worth noting that Testers page points you to another wiki page, https://wiki.freepascal.org/index.php?title=How_to_start that tells you how to run the "testsuite". For that you need a source install (not the packages at https://downloads.freepascal.org/fpc/beta/3.2.4-rc1) and the process is not completely clear. But quite doable ! (assuming Linux here.) Firstly, you will be running make in the fpc324rc1 source tree, and that requires you to use fpc322. So, fiddle the PATH accordingly if you have it installed. Its will almost certainly build OK. Then, to run the testsuite, restore your PATH so it points again, to fpc324 but the makefile also requires you to point to new compiler on the command line - Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  $> make clean all digest TEST_FPC=/home/dbannon/fpc-3.2.4/bin/fpc The Wiki page tells you to compare testsuite to previous results but I don't have any previous results !  So, I'll post to the Testers page. I think... Davo ---------------------------------------------------------------------- abouchez · 2025-06-24 09:26 One remark: In a Release Candidate, should not the VER_3_2_4 conditional be defined? Also the %FPCVERSION% macro seems to return 3.2.3. To my understanding, a RC is exactly the same as a final Release, but without official approval. It may be committed without any modification in its final state, if there is no stopping bug. I tested it with mORMot trunk, and all tests did pass successfully on Linux x86_64. So this release sounds in a good shape: https://gist.github.com/synopse/a43b0ec86edd995fc7de346ab8862fc5 ---------------------------------------------------------------------- Thaddy · 2025-06-24 09:55 Yes, I already pointed out the fixes branch should be 3.2.5 because a release rc is basically frozen. From that branch you can then do backports to the RC until final release. ---------------------------------------------------------------------- domasz · 2025-06-24 11:38 Quote from: PascalDragon on June 23, 2025, 03:29:04 pmPackages: fcl-pdf: pdf reader Any example for that? ---------------------------------------------------------------------- marcov · 2025-06-24 11:42 Quote from: domasz on June 24, 2025, 01:38:33 pmQuote from: PascalDragon on June 23, 2025, 03:29:04 pmPackages: fcl-pdf: pdf reader Any example for that? Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i c:\repo\fpc\packages\fcl-pdf\examples>grep -i read *pdfdump.pp  F:=TFileStream.Create(FN,fmOpenRead or fmShareDenyWrite);simpleread.ppprocedure ReadPDF(const aStream: TStream; aDoc: TPDFDocument);    Writeln('Usage : simpleread filename');    ReadPDF(F,Doc);simpleread2.pp    Writeln('Usage : simpleread filename');testfppdf.lpr  fpreadjpeg,  The last one seems to read jpgs to write them into the PDF, but the rest looks like reading demos. ---------------------------------------------------------------------- MarkMLl · 2025-06-24 19:28 TFT Sven, I'll try to take a look. MarkMLl ---------------------------------------------------------------------- domasz · 2025-06-25 07:05 Thanks, marcov! ---------------------------------------------------------------------- etrusco · 2025-06-25 12:23 I guess the x86_64-win64 situation (https://gitlab.com/freepascal.org/fpc/source/-/issues/32848) should be mentioned on the release notes? ---------------------------------------------------------------------- PascalDragon · 2025-06-25 20:30 Quote from: etrusco on June 25, 2025, 02:23:30 pmI guess the x86_64-win64 situation (https://gitlab.com/freepascal.org/fpc/source/-/issues/32848) should be mentioned on the release notes? No, because it is that way since forever. ---------------------------------------------------------------------- etrusco · 2025-06-25 23:31 Quote from: PascalDragon on June 25, 2025, 10:30:55 pmQuote from: etrusco on June 25, 2025, 02:23:30 pmI guess the x86_64-win64 situation (https://gitlab.com/freepascal.org/fpc/source/-/issues/32848) should be mentioned on the release notes? No, because it is that way since forever. But new users arrive and get confused. ---------------------------------------------------------------------- AlexTP · 2025-07-03 14:06 This post https://forum.lazarus.freepascal.org/index.php/topic,71653.m sg559621.html#msg559621 mentions commit which is needed to work with 'q0' register on aarch64. Is it merged? Thank you for the attention to this matter! ---------------------------------------------------------------------- Thaddy · 2025-07-03 14:10 No. Trunk only. ---------------------------------------------------------------------- Espectr0 · 2025-07-05 15:03 I replace this version with Lazarus 4 version 3.2.2 and that's it? ---------------------------------------------------------------------- Thaddy · 2025-07-05 15:38 No, the register updates for AARCH64 are only in 3.3.1. not in 3.2.4 nor 3.2.2. It is the compiler, not Lazarus. Lazarus is NOT a compiler. FPC is... ---------------------------------------------------------------------- Espectr0 · 2025-07-05 15:41 I mean, is it enough to replace 3.2.2 with 3.2.4? ---------------------------------------------------------------------- Thaddy · 2025-07-05 15:45 No. The RC1 3.2.4 does not contain the AARCH64 updates. Just Main/Trunk does: 3.3.1. ---------------------------------------------------------------------- robert rozee · 2025-07-06 11:10 Quote from: PascalDragon on June 23, 2025, 03:29:04 pmThe main highlights of this version: Issues with newer glibc fixed hi PascalDragon,     what are the nature of these fixes? do they resolve the symbol versioning issues that block binaries built on newer Linux systems from being run on older systems? cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2025-07-06 12:03 Quote from: robert rozee on July 06, 2025, 01:10:58 pm    what are the nature of these fixes? do they resolve the symbol versioning issues that block binaries built on newer Linux systems from being run on older systems? That would be a quite major change, so unlikely in a fixes point release. So probably no. And if it is not in trunk, it won't be in a fixes release to begin with. If you have specific revisions in trunk, I can lookup some status. ---------------------------------------------------------------------- PascalDragon · 2025-07-06 13:06 Quote from: robert rozee on July 06, 2025, 01:10:58 pm    what are the nature of these fixes? Removal of some symbols from newer libc versions. Quote from: robert rozee on July 06, 2025, 01:10:58 pm do they resolve the symbol versioning issues that block binaries built on newer Linux systems from being run on older systems? No. ---------------------------------------------------------------------- robert rozee · 2025-07-06 13:20 Quote from: PascalDragon on July 06, 2025, 03:06:17 pmQuote from: robert rozee on July 06, 2025, 01:10:58 pm    what are the nature of these fixes? Removal of some symbols from newer libc versions. [...] are you saying that there are some symbols, present in earlier glibc versions, that are no longer present in current versions of glibc?! from my dealings with the glibc developers a year or two back, i understood that we had a promise that no symbols would ever be removed - thereby guaranteeing a level of version compatibility provided a few simple rules were followed. cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2025-07-06 13:27 Quote from: robert rozee on July 06, 2025, 03:20:15 pmare you saying that there are some symbols, present in earlier glibc versions, that are no longer present in current versions of glibc?! from my dealings with the glibc developers a year or two back, i understood that we had a promise that no symbols would ever be removed - thereby guaranteeing a level of version compatibility provided a few simple rules were followed. Only when linked with the corresponding crt* files. FPC has its own, that sometimes causes problems. ---------------------------------------------------------------------- PascalDragon · 2025-07-06 13:52 Quote from: robert rozee on July 06, 2025, 03:20:15 pmQuote from: PascalDragon on July 06, 2025, 03:06:17 pmQuote from: robert rozee on July 06, 2025, 01:10:58 pm    what are the nature of these fixes? Removal of some symbols from newer libc versions. [...] are you saying that there are some symbols, present in earlier glibc versions, that are no longer present in current versions of glibc?! from my dealings with the glibc developers a year or two back, i understood that we had a promise that no symbols would ever be removed - thereby guaranteeing a level of version compatibility provided a few simple rules were followed. See here. ---------------------------------------------------------------------- PeterBB · 2025-09-03 11:45 I've noticed a project of mine that builds fine on multiple Linux distros, now fails to build on Fedora Rawhide. The reason being, that unlike the others, Rawhide now uses 3.2.4-rc1. Seems to me there is a problem, at least with the documentation Quoteintentional changes made to the FPC compiler (3.2.4) since the previous release that may break existing code .... Full log is here; https://build.opensuse.org/package/live_build_log/home:PeterBBB/c- evo/Fedora_Rawhide/x86_64 Error message is Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i    33s] (3104) Compiling UListViewSort.pas[   33s] /home/abuild/rpmbuild/BUILD/c-evo-dh-3.0-build/c-evo-dh-3.0/c-evo- dh-3.0/Packages/Common/UListViewSort.pas(351,59) Error: (4025) Incompatible type for arg no. 1: Got "ListViewCompare(constref TObject;constref TObject):LongInt;", expected ""[   33s] /usr/lib64/fpc/3.2.3/units/x86_64-linux/rtl- generics/generics.defaults.ppu:generics.defaults.pas(58,20) Hint: (5039) Found declaration: class Construct(const TComparisonFunc$1$crcE9FF3F60):IComparer$1;[   33s] /usr/lib64/fpc/3.2.3/units/x86_64-linux/rtl- generics/generics.defaults.ppu:generics.defaults.pas(57,20) Hint: (5039) Found declaration: class Construct(const TOnComparison$1$crcE9FF3F60):IComparer$1;[   33s] UListViewSort.pas(573) Fatal: (10026) There were 1 errors compiling module, stopping[   33s] Fatal: (1018) Compilation aborted   Code module is here; https://sourceforge.net/p/c-evo- eh/code/ci/master/tree/Packages/Common/UListViewSort.pas ---------------------------------------------------------------------- PeterBB · 2025-09-03 11:51 Ah! On second thoughts, is this the constref -> const issue described under  "Generics.Collections & Generics.Defaults" ? Cheers, Peter Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Got "ListViewCompare(constref TObject;constref TObject):LongInt;", expected "" ---------------------------------------------------------------------- Thaddy · 2025-09-03 12:07 See https://wiki.freepascal.org/User_Changes_Trunk#Generics.Collection s_&_Generics.Defaults : It is in trunk, but not 3.2.4. It is back-ported indeed: https://wiki.freepascal.org/User_Changes_3.2.4#Generics.Collections_&_ Generics.Defaults. That causes an incompatibility between3.2.2 and 3.2.4 regarding generics.collections and generics.defaults ---------------------------------------------------------------------- PeterBB · 2025-09-03 13:01 A couple of questions then. Will code changed to compile in 3.2.4 be likely still to compile with <= 3.2.2, or will IFDEFs be needed? Does Lazarus (official release version) compile with 3.2.4? Cheers, Peter ---------------------------------------------------------------------- Thaddy · 2025-09-03 13:55 It is not perse a breaking change, only when you mis-use or abuse const vs constref. Then you need to adjust the procedure/function/method prototype. And only for rtl-generics.(at least as it stands) I think it is highly unlikely it breaks  code for that reason, but it IS possible. OTOH, now it is Delphi compatible. Breaking code is likely BASM anyway and caused by mr and/or mrs knowitall's "programming skills" eventually. Horrible family, those. ---------------------------------------------------------------------- PeterBB · 2025-09-03 15:36 Quote from: Thaddy on September 03, 2025, 03:55:56 pmBreaking code is likely BASM anyway and caused by mr and/or mrs knowitall's "programming skills" eventually. Hi Thaddy, Presumably not a reference to the Buddhist Association of Southwest Michigan  The failing routines were not written by me BTW. Anyway, I have only found two uses of constref in the entire codebase, so its turned out to be rather a storm in a teacup. Cheers, Peter ---------------------------------------------------------------------- marcov · 2025-09-03 15:55 Quote from: PeterBB on September 03, 2025, 05:36:52 pmPresumably not a reference to the Buddhist Association of Southwest Michigan  The inline assembler was originally called BASM in TP/Delphi. It was a mind jump for me too, but I think he means that only when you use it from assembler you get no compiler warning. Nevertheless that it is fixable, it is a breakage. Which is unfortunate, but sometimes it simply has to happen because otherwise a whole lot of other fixes are also held up, specially with the current release rate. ---------------------------------------------------------------------- 440bx · 2025-09-07 17:38 question about v3.2.4... does it support using an underscore (_) as thousands separator ? thank you. ---------------------------------------------------------------------- Thaddy · 2025-09-07 17:44 No. See new features trunk. https://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_Digit_S eparator To my knowledge it is not back-ported, because it is a feature, not a bug-fix, ---------------------------------------------------------------------- 440bx · 2025-09-07 17:50 Thank you Thaddy. That's really too bad.  That's a simple feature but, it really enhances code readability. ---------------------------------------------------------------------- flowCRANE · 2025-09-07 18:19 Is there any tentative (approximate) release date for this FPC version as stable, included with a stable future version of Lazarus? ---------------------------------------------------------------------- Martin_fr · 2025-09-07 18:43 Quote from: flowCRANE on September 07, 2025, 08:19:43 pmIs there any tentative (approximate) release date for this FPC version as stable, included with a stable future version of Lazarus? Don't know about the FPC schedule. Lazarus will most likely release a next minor update, within weeks of the release of fpc 3.2.4. If you are on Windows, there is a non-official build of the current Lazarus 4.2 with the 3.2.4RC https://sourceforge.net/projects/lazarus- snapshots/files/Window%2064/2025- 07%20Lazarus%204.2%20with%20FPC%203.2.4-RC1%20(56baf314b5eb)/ (32 bit version is also there) ---------------------------------------------------------------------- flowCRANE · 2025-09-07 19:32 I didn't know there were unofficial releases — I'll definitely check out this version. Thanks! ---------------------------------------------------------------------- Martin_fr · 2025-09-07 20:15 Quote from: flowCRANE on September 07, 2025, 09:32:32 pmI didn't know there were unofficial releases — I'll definitely check out this version. Thanks! "build" not "release", aka snapshot. Albeit, its been build the same as the release, and with the same Lazarus files. (and it's even code signed, same as the release).  Personally, I think the 3.2.4RC is already better than the 3.2.2. And the IDE has been used with it for some time as well. E.g. I build my IDE most of the time with 3.2.3 (which is close to the RC). It's possible that some packages will require updates, if they haven't been tested yet (though I expect the majority to be fine). If any needs to be adjusted then that is a matter of bug reporting it (I.e. the team simple can't test all OPM packages themself, this will and has always relayed on feedback) ---------------------------------------------------------------------- Thaddy · 2025-09-08 04:49 Only known breaking change is the constref --> const issue in rtl- generics. ---------------------------------------------------------------------- cdbc · 2025-09-12 14:21 Hi Please, would someone be so kind and backport 'RTLString' from trunk into 3.2.4 final... Pretty Please  It has to happen sooner or later, so why not now...? Regards Benny ---------------------------------------------------------------------- 440bx · 2025-09-12 14:32 I'd like to see a _formal_ release made of all the bug fixes and _simple_ features. Such a release would not require many documentation changes and would not require as much testing as a release that includes advanced/complex features. t would also be a good stepping stone to the next "large" formal release since it would help uncover bugs by having a larger number of users (than an informal version.) ---------------------------------------------------------------------- Thaddy · 2025-09-12 15:59 Benny, Why do you need it? Unless you are one of the few (inc. me, but I keep it separate) that compiles the rtl with namespaces and therefor UTF16 string, it is just AnsiString, also for UTF8.(with cp_utf8). Unless you port a lot of code from modern Delphi's. The feature relies on more new feautures and these would also have to be back-ported and those carry a risk, because they are complex. That won't happen. 3.2.4. is a bug fix release. ---------------------------------------------------------------------- cdbc · 2025-09-12 16:58 Hi Thaddy Ok, I understand  ...and I know all that, but still had a naïve wish...  I'll just keep on "IfDef'ing"  Regards Benny ---------------------------------------------------------------------- Martin_fr · 2025-10-03 18:57 Likely affecting the RC / Found in 3.2.3 420f7af213 There is an issue in the code generator. Under some circumstances inlined code will use the same physical memory in its stackframe for one of its own locals (params), as the containing code does use for one of its locals. Actually, it overwrites the local var of the caller, that is the var the caller passed as arguments. So it behaves as if the param was a "var param" => but it is not... This happens with peephole disabled. ---- More to follow. ---------------------------------------------------------------------- Martin_fr · 2025-10-03 21:15 https://gitlab.com/freepascal.org/fpc/source/-/issues/41431 ---------------------------------------------------------------------- pleumann · 2025-11-07 17:53 Thanks for your effort, guys! I'm really looking forward to the new version! Is there any chance that someone has a look at fixing stack traces (-gl) for MacOS in this release or is it too late / too difficult? ---------------------------------------------------------------------- PascalDragon · 2025-11-08 17:26 Quote from: pleumann on November 07, 2025, 06:53:04 pmIs there any chance that someone has a look at fixing stack traces (-gl) for MacOS in this release or is it too late / too difficult? Is this even fixed in main? If not, though luck. ---------------------------------------------------------------------- pleumann · 2025-11-09 10:37 Quote from: PascalDragon on November 08, 2025, 06:26:08 pmQuote from: pleumann on November 07, 2025, 06:53:04 pmIs there any chance that someone has a look at fixing stack traces (-gl) for MacOS in this release or is it too late / too difficult? Is this even fixed in main? If not, though luck. I admit I didn't check. And I've never tried to build FPC from source (as opposed to Lazarus, which I routinely build myself). Maybe I should. I was kind of hoping that it's just a small glitch in the specific binary format that slipped into 3.2.2 back then and broke stack traces for MacOS. Is there an open ticket for it? I did search the issue tracker, but couldn't find anything (maybe due to using the wrong search terms). Anyway, this is really my biggest wish for 3.2.4 or another (hopefully not too distant) future version of FPC. Debugging without getting source code information in case of a crash is really a major PITA. ---------------------------------------------------------------------- Martin_fr · 2025-11-09 10:56 Quote from: pleumann on November 09, 2025, 11:37:38 amQuote from: PascalDragon on November 08, 2025, 06:26:08 pmQuote from: pleumann on November 07, 2025, 06:53:04 pmIs there any chance that someone has a look at fixing stack traces (-gl) for MacOS in this release or is it too late / too difficult? Is this even fixed in main? If not, though luck. I think, I've read in another post that it is implemented in 3.3.1. But I have not tested myself. Quote Debugging without getting source code information in case of a crash is really a major PITA. In general (and afaik it works on Mac, but I don't have one to test), if - you get the trace with addresses only - and your app has debug info then you can in Lazarus go to menu: View > Leaks and traces. Paste the addresses there, press resolve and select the exe (not sure if that is the bundle, or the exe inside the bundle...). And then you should get the addresses. Outside of Lazarus, there may be a way to translate addresses using lldb (or gdb), but that is more work... ---------------------------------------------------------------------- pleumann · 2025-11-09 16:12 Quote from: Martin_fr on November 09, 2025, 11:56:28 amQuote from: pleumann on November 09, 2025, 11:37:38 amQuote from: PascalDragon on November 08, 2025, 06:26:08 pmQuote from: pleumann on November 07, 2025, 06:53:04 pmIs there any chance that someone has a look at fixing stack traces (-gl) for MacOS in this release or is it too late / too difficult? Is this even fixed in main? If not, though luck. I think, I've read in another post that it is implemented in 3.3.1. But I have not tested myself. Quote Debugging without getting source code information in case of a crash is really a major PITA. In general (and afaik it works on Mac, but I don't have one to test), if - you get the trace with addresses only - and your app has debug info then you can in Lazarus go to menu: View > Leaks and traces. Paste the addresses there, press resolve and select the exe (not sure if that is the bundle, or the exe inside the bundle...). And then you should get the addresses. Outside of Lazarus, there may be a way to translate addresses using lldb (or gdb), but that is more work... My main/problem use case is a command-line app (Lazarus apps I can simply run through the debugger and catch exceptions there). When I compile with "-gl" for Windows or Linux, I get file/line info in case of a crash (like a range error or so). For MacOS (both Intel and Arm) I only get the list of addresses. I assume that basically the same mechanism at work for all three platform (at least the docs didn't seem to contain an obvious hint that I need to do something special for MacOS). Pasting the hex address into a dialog and letting the compiler resolve it reminds me of Turbo Pascal 3.0 or even earlier. But thanks for the hint. I might try that. If it works it's still better than plastering the code with WriteLn statements. ---------------------------------------------------------------------- JdeHaan · 2025-11-10 20:40 Next to -gl also include -Xg (Use external debug symbols file). That might help. ---------------------------------------------------------------------- freq · 2025-11-19 10:51 Hi, I recently updated to macOS 26 and still get the "malformed method list atom 'ltmp5' or 'ltmp4'" linker error with FPC 3.2.4-rc1 as well as with main branch FPC 3.3.1. Is that issue adressed at all? Of coarse the -WM10.9 flag helps. Compiling for aarch64. Best ---------------------------------------------------------------------- PascalDragon · 2025-11-20 21:44 Was that even reported? I can't find something related to this in the issue tracker, so if none of the developers didn't find it by accident by themselves, then of course it's not fixed. ---------------------------------------------------------------------- Thaddy · 2025-11-21 09:30 Although I can understand that our M4's did have some difficulties - solved-  to install on, the question you answered is not repeatable. Looks bogus to me and without further information I can not test that. (and that was the reason I bought it in the first place) ---------------------------------------------------------------------- PeterBB · 2025-11-29 11:46 Quote from: Martin_fr on October 03, 2025, 08:57:17 pmLikely affecting the RC / Found in 3.2.3 420f7af213 There is an issue in the code generator. Under some circumstances inlined code will use the same physical memory in its stackframe for one of its own locals (params), as the containing code does use for one of its locals. Ouch!   Can inlining be completely disabled somehow? I notice that Lazarus source makes extensive use of the 'inline;' directive. Also I'm curious as to what compilation option '-uni' does (in issue 41431). Cheers, Peter ---------------------------------------------------------------------- Thaddy · 2025-11-29 15:27 Why would you want to disable it? But yes if you want slower  code you can use {$inline off} in your units locally or use the global commandline option -Si- (or -O- a.k.a. everything off) I guess you do not fully understand what inline does and where to use it? Strange question. Also note inline is a hint: there is no guarantee that the compiler will inline everything that is marked inline. ---------------------------------------------------------------------- PeterBB · 2025-11-29 16:25 Quote from: Thaddy on November 29, 2025, 04:27:26 pmWhy would you want to disable it? Because I would like to do some testing with 3.2.4-rc1, but that seems pointless given https://gitlab.com/freepascal.org/fpc/source/-/issues/41431 unless there is a way to guarantee that inlining (which can generate bad code) is always disabled, even when the 'inline;' directive is used. Any ideas regarding the -uni option (in the linked bug report, "Steps to Reproduce")? Cheers, Peter ---------------------------------------------------------------------- Martin_fr · 2025-11-29 16:38 Quote from: PeterBB on November 29, 2025, 05:25:28 pmBecause I would like to do some testing with 3.2.4-rc1, but that seems pointless given https://gitlab.com/freepascal.org/fpc/source/-/issues/41431 Just to add, I tested https://gitlab.com/freepascal.org/fpc/source/- /issues/41431#note_2815280197 with the current 3.2.2 => same bug. ---------------------------------------------------------------------- PeterBB · 2025-11-29 17:43 Quote from: Martin_fr on November 29, 2025, 05:38:35 pmQuote from: PeterBB on November 29, 2025, 05:25:28 pmBecause I would like to do some testing with 3.2.4-rc1, but that seems pointless given https://gitlab.com/freepascal.org/fpc/source/-/issues/41431 Just to add, I tested https://gitlab.com/freepascal.org/fpc/source/- /issues/41431#note_2815280197 with the current 3.2.2 => same bug. Ah, thanks for clarifying. I had assumed incorrectly that this was a regression. ---------------------------------------------------------------------- Graeme · 2025-12-11 22:15 Quote from: PascalDragon on June 25, 2025, 10:30:55 pmQuote from: etrusco on June 25, 2025, 02:23:30 pmI guess the x86_64-win64 situation (https://gitlab.com/freepascal.org/fpc/source/-/issues/32848) should be mentioned on the release notes? No, because it is that way since forever. About 10 years later, and there is still no official 64-bit release for Win64? I know it's simple to compile one yourself - I've done that for over a decade, but come on. 32-bit windows hasn't been a [Microsoft] thing for very long now. ---------------------------------------------------------------------- dbannon · 2025-12-11 23:02 Quote from: Graeme on December 11, 2025, 11:15:52 pmAbout 10 years later, and there is still no official 64-bit release for Win64? I know it's simple to compile one yourself - I've done that for over a decade, but come on. 32-bit windows hasn't been a [Microsoft] thing for very long now. Oh, come on Graham, its over four years since we had an official release for ANY Platform ! Davo ---------------------------------------------------------------------- dsiders · 2025-12-11 23:59 Quote from: Graeme on December 11, 2025, 11:15:52 pmQuote from: PascalDragon on June 25, 2025, 10:30:55 pmQuote from: etrusco on June 25, 2025, 02:23:30 pmI guess the x86_64-win64 situation (https://gitlab.com/freepascal.org/fpc/source/-/issues/32848) should be mentioned on the release notes? No, because it is that way since forever. About 10 years later, and there is still no official 64-bit release for Win64? I know it's simple to compile one yourself - I've done that for over a decade, but come on. 32-bit windows hasn't been a [Microsoft] thing for very long now. The Lazarus installer for Windows 64-bit includes a 64-bit compiler. ---------------------------------------------------------------------- marcov · 2025-12-12 09:47 Quote from: Graeme on December 11, 2025, 11:15:52 pmAbout 10 years later, and there is still no official 64-bit release for Win64? I know it's simple to compile one yourself - I've done that for over a decade, but come on. 32-bit windows hasn't been a [Microsoft] thing for very long now. FPC 3.2.4RC1 has a win32/win64 combo installer.  (so win32 + win64 crosscompiler in one installer) ---------------------------------------------------------------------- PeterBB · 2025-12-13 19:31 I've set up the release candidate on the Arch AUR here; https://aur.archlinux.org/packages/fpc-rc Note, to try out with lazarus, it will be necessary to rebuild lazarus first, otherwise, will get those dreaded "checksum changed" issues! Cheers, Peter ---------------------------------------------------------------------- AlexTP · 2026-02-21 16:44 https://gitlab.com/freepascal.org/fpc/source/-/blob/release_3_2_4- branch/packages/libfontconfig/fpmake.pp?ref_type=heads File fpmake.pp shows that this 'libfontconfig' package is not compiled for Solaris OS. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  P.OSes := [linux] + AllBSDOses; // Darwin was tested! But in the 3.3 Git main, this package IS compiled for Solaris OS. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i   P.OSes := [linux, solaris] + AllBSDOses; // Darwin was tested!   Can you add Solaris support in 3.2.4? ---------------------------------------------------------------------- msohn · 2026-02-27 07:29 AFAICS https://gitlab.com/freepascal.org/fpc/source/- /commit/0758aa1143a6498532b3d100ed15edd63ca878b6 has not made it into 3.2.4, correct? That is an absolute show-stopper for me and will also make it impossible to use fpcupdeluxe on the next version of macOS (27?) which will no longer support Rosetta, i.e. running x86_64 code on Apple Silicon. Could this please be considered for a back port? ---------------------------------------------------------------------- zeljko · 2026-02-27 09:22 Have you tried to merge that commit into 3.2.4 source ? Tested it ? ---------------------------------------------------------------------- dbannon · 2026-02-27 10:13 Wow, thats one serious commit. Just about every platform individually affected ? No description about what it does, or why or how to test it. Two and a half years ago ? msohn, you might need some help to get going some other way. Why does this problem particularly affect fpcupdeluxe ? Probably others ?  I build my app for Mac Arm users by cross compiling from an Mac Intel box and make a AARCH64 binary, there seems to be lots of other Mac users here using AARCH64 binaries. Why are you locked into Rosetta model ? Davo ---------------------------------------------------------------------- msohn · 2026-02-27 11:21 Yes it is a serious commit. I've been using it together with https://g itlab.com/freepascal.org/fpc/source/- /commit/c89848a00f59cc2539c5ff3862a547218129f594 (which contains the description the other commit was missing!) on top of FPC 3.2.2 for years now. The problem with fpcupdeluxe is the bootstrap compiler it brings with it - for aarch64 that is the original 3.2.2 having the bug, so any FPC you're trying to build will crash - rendering the fpcupdeluxe useless, so one has to use the x86_64 version and build a cross compiler for aarch64 with it. That is what everyone seems to be doing until now, but that won't work anymore if you're on an OS that no longer has Rosetta. See also https://github.com/LongDirtyAnimAlf/fpcupdeluxe/issues/754, that is just one of many issues that users have been reporting there. I just successfully made this work on the fixes_3_2 branch and verified that the fix is indeed working on aarch64. I cherry picked the first commit (0758aa11) and resolved all conflicts by choosing the file from that commit as is. I discarded all new files in that commit as I presumed these have been removed platforms (that also applies to the commit c89848 linked above). I'll gladly provide a patch or open an issue on GitLab if that helps getting these fixes into 3.2.4! ---------------------------------------------------------------------- Graeme · 2026-02-27 16:09 Quote from: dbannon on December 12, 2025, 12:02:09 amOh, come on Graham, its over four years since we had an official release for ANY Platform ! Time to live dangerously and build FPC Trunk*.  🤣 * https://gitlab.com/freepascal.org/fpc/source/ ---------------------------------------------------------------------- ALLIGATOR · 2026-02-27 16:52 I may soon be banned from this forum But, as always, I'll add my two cents There's nothing wrong with FPC [main] ---------------------------------------------------------------------- dbannon · 2026-02-28 00:43 Quote from: msohn on February 27, 2026, 12:21:10 pm... so one has to use the x86_64 version and build a cross compiler for aarch64 with it. OK, so if that works it would also be possible to cross compile from an Intel Mac to a aarch64 FPC binary ? I am thinking of a "work around" until a suitable FPC fix happens. I have a system, for my one use, that allows me to put an up-to-date (ie rc1) FPC on a system without compiling it there. My 'library' of precompiled FPC already already includes an Intel Mac one. Separately, I already cross compile my app to aarch64, sounds like I could, easily, add a aarch64 FPC rc1 to that 'library' ? https://github.com/davidbannon/FPC_Laz_Install - The install script has not been extensively tested on the Mac as I only have one, got it worked and stopped. I don't have a Mac aarch64 machine. But if you would like to experiment ... QuoteI just successfully made this work on the fixes_3_2 branch and verified that the fix is indeed working on aarch64. The issue there (I suspect, don't know) is testing on all the affected platforms. You have obviously tested on aarch64, how about making the patched source available so others can test on other platforms. I can do Linux [i386, x86_64, armhf, aarch64] maybe expressif. Who knows who else is listening in to this conversation ? A clear description, or auto test, so we can be sure of the test results. I guess a patch against the current 3.2.4rc1 ?   Or maybe the branch? No idea which the devs would prefer. It might help, maybe we would be wasting our time but lets find out ? Davo ---------------------------------------------------------------------- msohn · 2026-02-28 14:21 Do you fully understand the broad effects this bug has? If you're building an app or dylib with aarch64 FPC 3.2.x and it contains any floating point math (hard to avoid, esp. if you link to other code, e.g. dylibs, frameworks etc.) and more than a single thread, you're bound for a hard crash. If you dig through it, https://gitlab.com/freepascal.org/fpc/source/-/issues/38230 has a lot of info from the commits author. The bug is known for more than 5 years now, the fix is in trunk for 3.5 years, so I would consider it sufficiently tested. My concern is that eventually it will be difficult to find a Mac that can still run x86_64. So you would have to use a different platform, e.g. Linux or Windows to build the cross-compiler and then you'd need to come up with a way of "installing" it on the Mac, like you apparently did. Nothing impossible, but far from the convenience of fpcupdeluxe. I still hope one of the devs would consider the fix for 3.2.4. If so, I can try to provide whatever is needed. ---------------------------------------------------------------------- PascalDragon · 2026-02-28 17:35 Quote from: ALLIGATOR on February 27, 2026, 05:52:44 pmThere's nothing wrong with FPC [main]  If it works for you, great, but that is not the case for everyone and it currently contains enough major issues that definitely don't make us recommend using main for productive use compared to 3.2.2. ---------------------------------------------------------------------- dbannon · 2026-03-03 09:25 Quote from: PascalDragon on February 28, 2026, 06:35:36 pmIf it works for you, great, but that is not the case for everyone and it currently contains enough major issues that definitely don't make us recommend using main for productive use compared to 3.2.2. Which brings us back, nicely, to the title of this thread, FPC 3.2.4rc1, better than 3.2.2, safer than main. Please ! Davo ---------------------------------------------------------------------- wpostma · 2026-04-18 03:53 So when WILL this be released?  The last binary release on the downloads page was FOUR years ago. Just wonderin. The free pascal package is gone from debian, gone from homebrew,  and really, it looks like some effort should be made to you know, ship a binary some time before 2029. W ---------------------------------------------------------------------- 440bx · 2026-04-18 04:08 Quote from: wpostma on April 18, 2026, 05:53:48 amJust wonderin. Quite likely you have a lot of company ---------------------------------------------------------------------- Fred vS · 2026-04-18 11:36 It's truly sad to see FPC lose its luster and sink. Great projects like PTCpas no longer work on the latest versions of Windows 11, OpenBSD has removed the FPC package, …  :'( ---------------------------------------------------------------------- marcov · 2026-04-18 13:02 Quote from: wpostma on April 18, 2026, 05:53:48 amSo when WILL this be released?  The last binary release on the downloads page was FOUR years ago. Just wonderin. The free pascal package is gone from debian, gone from homebrew Debian was temporary due to the wayland-gtk2 wars requiring to sort themselves out.  E.g. https://packages.debian.org/testing/devel/fp-ide I don't know homebrew, but take that up with its maintainers. It is outside of our control. Quote and really, it looks like some effort should be made to you know, ship a binary some time before 2029. Not news. But I currently have no concrete news to give either. ---------------------------------------------------------------------- robert rozee · 2026-04-18 13:42 Quote from: wpostma on April 18, 2026, 05:53:48 amSo when WILL this be released?  The last binary release on the downloads page was FOUR years ago. read this developers discussion, in particular the threads titled "134 open merge requests - is that normal?" and "[RFC] Modernising the FPC Release Process...": https://lists.freepascal.org/pipermail/fpc-devel/2026-April/date.html essentially, the FPC development 'team' is paralyzed by the overwhelming volume of changes submitted since FPC 3.2.2 was released almost 5 years ago; it looks like the vast majority of those changes have been submitted by the developers themselves, although that in itself is no sin. however, few of the developers appear to have any appetite, personally, for sifting through those those changes and turning them into a new release/releasable version, rather each more having interests in submitting further changes to add new enhancements and features of personal interest to each developer. i place the word 'team' in single quote marks as, from the practical perspective there is no longer an FPC development team. what there is, is a collection of knowledgeable FPC developers, each with vastly different ideas, each pursuing their own interests of tinkering with the FPC compiler. there is no "team effort" there, and as time rolls on the state of paralysis becomes ever more entrenched. cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2026-04-18 13:51 Quote from: robert rozee on April 18, 2026, 03:42:35 pmQuote from: wpostma on April 18, 2026, 05:53:48 amSo when WILL this be released?  The last binary release on the downloads page was FOUR years ago. read this developers discussion, in particular the threads titled "134 open merge requests - is that normal?" and "[RFC] Modernising the FPC Release Process...": https://lists.freepascal.org/pipermail/fpc-devel/2026-April/date.html Those threads do not analyse the reasons for that. They only express hope from one FPC developer (Michael) and one external contributor (Graeme) that more fully changing the workflow to suit git  _MIGHT_ do something about it. Several developers have expressed concern, so this is not an universal view. Note that the workflow change advocates don't analyse at all what goes wrong with releasing, but simply blame every delay on workflow. Assuming that any acceleration to be had from workflow changes will magically relieve the release paralysis.  It won't.  It only would slightly automatise work that is normal and continuously done in the past, and never was a bottleneck. And it does nothing to fix paralysis around bigger decisions, it only automates routine work a bit more (and even that can be debated, depending on preferences) But consider this:  They have done the similar proposals during the gitlab migration, and in fact the release slow down started with the git(lab) migration. Now that is not entirely fair, there were many other contributing factors, but the upheaval didn't help.  Also that the gitlab migration was pushed through without regarding how to release in the future. It was all "oh we'll write some scripts", but those scripts were 1.5 years in the coming. The reason for that push was decided so short term, was mostly because the leased servers were up for renewal and significantly more expensive, and that times required for maintenance of the leased servers had grown too over the years. I would say accounts at least for 1.5 to 2 years of the delay. Specially 3.2.4, which would have come out in 2022 or maybe a bit delayed in 1H 2023 due to corona if the GIT move hadn't be done. Do you really think changing everything now again will accelerate? More likely it will only cause more delay, as people start working on infrastructure rather than direct release work. And the portrayed schedules are always way too optimisitic. And keep in mind that I was release manager when releases were still somewhat on time, so I know what I'm talking about. ---------------------------------------------------------------------- Fred vS · 2026-04-18 14:06 @Marco : Blah, blah, blah, as usual. The only solution is to force a new release every 6 months. Period. ---------------------------------------------------------------------- robert rozee · 2026-04-18 14:15 Quote from: marcov on April 18, 2026, 03:51:34 pmThose threads do not analyse the reasons for that [...] true, but they do reveal the entrenched state of paralysis. there is no agreement, there is no leadership, there is no team. one does not need a detailed "analysis" to spot the dysfunction. i've pretty much concluded that FPC 3.2.2 is as good as it is going to get (FPC 3.2.4 RC1 for apple users). and this is not necessarily a bad thing, as FPC 3.2.2 is feature complete and pretty much ok for the vast majority of users. cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2026-04-18 14:19 Quote from: Fred vS on April 18, 2026, 04:06:30 pm@Marco : Blah, blah, blah, as usual. The only solution is to force a new release every 6 months. We already have snapshots. ---------------------------------------------------------------------- Fred vS · 2026-04-18 14:32 Quote from: robert rozee on April 18, 2026, 04:15:24 pmFPC 3.2.2 is feature complete and pretty much ok for the vast majority of users. Perhaps, but there are still easily fixable bugs. Unfortunately, even with the proposed fixes, some "core devs" remain very resistant to any change. Quote from: marcov on April 18, 2026, 04:19:39 pmWe already have snapshots. Of FPC 3.2.4 with regular fixes? If so, then there are no more valid excuses for not releasing a new version every 6 months. Logically, we should have a > 3.2.10 release by now. ---------------------------------------------------------------------- marcov · 2026-04-18 14:41 Quote from: robert rozee on April 18, 2026, 04:15:24 pmQuote from: marcov on April 18, 2026, 03:51:34 pmThose threads do not analyse the reasons for that [...] true, but they do reveal the entrenched state of paralysis. there is no agreement, there is no leadership, there is no team. one does not need a detailed "analysis" to spot the dysfunction. Yes. Dysfunction due to a migration that was bigger than we could chew. But that is not a reason to do another one. But the proposals only will divide the team more, and cause more delay. Also it only concerns future fixes branches. The workflow proponents don't really care about 3.2.4, and just want it done as quickly as possible (release as is without much quality control, maybe not even merge simple revisions in main to fixes, a process that stopped since fall 2024) to focus on their precious new workflow. And then, after the point of no return, the delays and excuses start. It was the same with gitlab migration, but at least that was not wholly a choice (see above server story) Also, I don't hate merge requests. They alleviate the possibilities for outsiders to contribute using a link between their version system and ours. But it is largely a side show. 1000 merge requests on a total of 14000 commits ? My doubts are in the extrapolating of benefits when you make merge requests central to everything is where I have enormous doubts. And even more if you apply it to release. There is hardly a relation there, it is all just marketing because the release crisis is a major topic in FPC atm.  The fact that he did this in fpc-devel instead of internal committer maillists says enough, as this change mostly affects the committers. He wanted to drum up support of the gullible anti everything (hi Fred!), and use that to force the other committer's hands with "popular support". But they have to do it now, because traditionally during and after preparation the x.y.4 release discussions over the next major branch start. If they don't force changes at that point, they are stuck with a fixes branch that isn't organised according to their principles. Quotei've pretty much concluded that FPC 3.2.2 is as good as it is going to get (FPC 3.2.4 RC1 for apple users). and this is not necessarily a bad thing, as FPC 3.2.2 is feature complete and pretty much ok for the vast majority of users. I need anonymous methods for work codebases.  Quite some generics and inline problems also have been fixed, and in general optimisation is in way better shape in main. Both from a feature as from a maintainability viewpoint. But if it works for you, I can imagine you feel no rush. ---------------------------------------------------------------------- Fred vS · 2026-04-18 14:58 Quote from: marcov on April 18, 2026, 04:41:21 pmHe wanted to drum up support of the gullible anti everything (hi Fred!), anti everything, your beautiful mirror! ---------------------------------------------------------------------- marcov · 2026-04-18 15:04 Quote from: Fred vS on April 18, 2026, 04:32:44 pmQuote from: robert rozee on April 18, 2026, 04:15:24 pmFPC 3.2.2 is feature complete and pretty much ok for the vast majority of users. Perhaps, but there are still easily fixable bugs. Unfortunately, even with the proposed fixes, some "core devs" remain very resistant to any change. Resistant against change with trumped up benefits, yes. And an all or nothing attitude. No starting small or doing experments, just our way or the highway for changes that affect the whole organisation of the new fixes branch. Everything. Do you think that is a positive mindset ? In the past big changes were always phased in by starting small and then expanding over time as experience with features grew. Since the gitlab migration (which was rammed through within 6 weeks, and nothing concrete was done for releasing), Michael suddenly wants to force everything without experimentation of phasing. Just some grand ideas, with argumentation that has enormous gaps, and as only choice giving him free reign or being essentially painted as the dinosaur that holds up all change. And that is why you are gullible Fred, because you believe that. But keep in mind that while I often say no, I'm at least here taking the time to answer your questions in detail. Quote from: Fred vS on April 18, 2026, 04:32:44 pmQuote from: marcov on April 18, 2026, 04:19:39 pmWe already have snapshots. Of FPC 3.2.4 with regular fixes? FPC 3.2.4 is not a live branch, but yes, of fixes (3.2.3), from which 3.2.4 was branched.  E.g. https://downloads.freepascal.org/fpc/snapshot/v32/i386-win32/ I think 3.2.3 is nearly equal to 3.2.4RC1, with maybe a few post RC1 fixes, despite having a lower number (3.2.3<3.2.4) Note that with snapshot I meant blessing a simple build as release without a proper process or investigation (are all things that can be merged really merged? Are there still showstopper changes?). Just because of the timer, do a build and bless it as release. The format might be different than a snapshot, but the checks on content are the same. And it is in those processes where the hangup is, not in the bulk merging as Michael argues on those threads. QuoteIf so, then there are no more valid excuses for not releasing a new version every 6 months. See my last posts on that thread. _I_  always did nearly all the merging, also in the GIT era. Michael merges only a fraction of his own changes (e.g. fcl-passrc and fcl-web where he does most work are hardly changed since 3.2.2). VCL-COMPAT is merged to a higher degree to fixes, but that was mostly done by yours truly, not Michael. The timer only signals that the current state is pushed out (and with only automated quality control, most of which stilll must be crafted, and probably never will for 3.2.4). It doesn't provide anything to make sure there is actually something in there. And such proposal from sb who never merged the bulk of his own changes to fixes is therefore doubtful. QuoteLogically, we should have a > 3.2.10 release by now. If this had been implemented in gitlab change times (when this was proposed), we might even be further.  But it would essentially contain the same as 3.2.2, as the timer does nothing about actually providing content. I don't mind going to a timebased schedule, but I want to see proposals to also tackle the release content side of things (and not try to create rosy coloured smoke screens by saying that automated systems from gitlab or AI will do everything). So back during the pre gitlab migration discussions, it was agreed that timebased schedule was a thing worth trying, but that we first would try to automate and accelerate the fixes release to find out what frequency was workable, and make sure that content wouldn't suffer. Joost and Michael would start working on that, and no progress report was ever received. To my knowledge they dabbled a bit in automating crosscompilation of the snapshots, but it was never finalised or evaluated. So the fact is that due to there never have been a release in the gitlab era, the effective automation of releases now is less than it was during 3.2.2 times. But Michael keeps blaming all release delays on automation, while not perfect, it wasn't any immediate cause. Asking all people what problems were remaining with a branch (e.g. processing RC1 feedback, and newer bugreports), and then actually fixing the remaining outstanding bugs was the problem, specially for the major releases. The actual building of the binaries mostly took the maintainers half an hour, and a bit more for the RCs.    I've build the windows RC1 binaries in hour (but that was mostly due to changes made to the innosetup), and the freebsd the day after in 2hrs.   Linux is a bit more complicated due to often emerging small problems in trying to remain the TGZ compatible with multiple distributions. I assume that OS X/iOS is also a bit more involved due to annual changes (both OS, as the XCode/binutils tooling it depends on, as well as new security features. Yes, maybe a script could do it all with a single button press, but building was always in weekends, and finding 2hrs to do it is not the reason for 5 year release hiatus. Read thread and my replies carefully, and check the things I say, and you'll see a pattern emerge. ---------------------------------------------------------------------- Fred vS · 2026-04-18 15:45 Quote from: marcov on April 18, 2026, 05:04:08 pmResistant against change with trumped up benefits, yes. And an all or nothing attitude. No starting small or doing experments, just our way or the highway for changes that affect the whole organisation of the new fixes branch. Everything. Do you think that is a positive mindset ? I think it's a negative mindset if the tested patches allow, for example, the use of an operating system (OpenBSD) that hasn't been accessible for five years. https://gitlab.com/freepascal.org/fpc/source/-/work_items/41017 (And the last patch-committed did not solve for OpenBSD 7.8. mine yes) Quote from: marcov on April 18, 2026, 05:04:08 pmSince the gitlab migration (which was rammed through within 6 weeks, and nothing concrete was done for releasing), Michael suddenly wants to force everything without experimentation of phasing. Just some grand ideas, with argumentation that has enormous gaps, and as only choice giving him free reign or being essentially painted as the dinosaur that holds up all change. And that is why you are gullible Fred, because you believe that. Hey, stop with the same old song, "It's because of GitLab." We all got it by now, you're hostile to Git. And Michael is a gem, an extremely talented creator, and an incredible stroke of luck for FPC to have him in its kernel. And you know what? Times are changing, the new vision is "we experiment as much as possible," a la Elon Musk (your good friend, I know). For the rest of your post, I agree with you, producing a release is a tedious task that requires a lot of energy and time. But it's part of the game and absolutely must be done, without excuses. ---------------------------------------------------------------------- marcov · 2026-04-18 16:57 Quote from: Fred vS on April 18, 2026, 05:45:33 pmI think it's a negative mindset if the tested patches allow, for example, the use of an operating system (OpenBSD) that hasn't been accessible for five years. Good luck with that. I hope it makes 3.2.4. If it is not in RC1, chances are slim IMHO. Quote from: Fred vS on April 18, 2026, 05:45:33 pmHey, stop with the same old song, "It's because of GitLab." Not gitlab per se , but the haphazard way it was forced through. I don't was not in favour of the gitlab itself, true, but I was ready to defer to other people's wishes and be constructive. But I warned back then that rushing it through and only caring about "MR to main" and forward branches could hurt releases. I stepped down, and guess what happened....... I don't think the others stopped releasing because of my gitlab negativity. So, maybe it is something else? What could it be ? Quotethe new vision is "we experiment as much as possible," a la Elon Musk (your good friend, I know). At least he has the cash to back it up. Mark Shuttleworth (of Ubuntu fame) might be a better IT relevant example though. QuoteFor the rest of your post, I agree with you, producing a release is a tedious task that requires a lot of energy and time. But it's part of the game and absolutely must be done, without excuses. And I did it for years. And I stopped because I got no cooperation during the gitlab migration, and nobody picked it up in an effective way afterwards. And that despite I did carry out my regular fixes merge jobs as good as possible as soon as it was made possible. It is not hard to verify, just check the FIXES_3_2 logs, and you'll see who did most of the merging of 3.2.4RC1. ---------------------------------------------------------------------- Fred vS · 2026-04-18 17:08 Quote from: marcov on April 18, 2026, 06:57:37 pmQuoteFor the rest of your post, I agree with you, producing a release is a tedious task that requires a lot of energy and time. But it's part of the game and absolutely must be done, without excuses. And I did it for years. And I stopped because I got no cooperation during the gitlab migration, and nobody picked it up in an effective way afterwards. Sorry to be blunt, but as the release manager, you, more than any other developer, should have eagerly embraced this new GitLab world and fully grasped it. Instead of waiting for others to do your work. ---------------------------------------------------------------------- marcov · 2026-04-18 18:08 Quote from: Fred vS on April 18, 2026, 07:08:05 pmQuoteAnd I did it for years. And I stopped because I got no cooperation during the gitlab migration, and nobody picked it up in an effective way afterwards. Sorry to be blunt, but as the release manager, you, more than any other developer, should have eagerly embraced this new GitLab world and fully grasped it. Instead of waiting for others to do your work. And I did, once after 1.5 years, Florian finally created a viable procedure for merging. I saw he updated some release engineering pages and scripts for 3.2.4rc1, so some things finally have been done. It is all down to the final execute. As I'm not release manager, I didn't keep tabs during the post 3.2.2 cycle, so I couldn't take over even if I wanted to. Anyway, both you, Graeme and Michael are barking up the wrong tree. My current commit rates are low, and even though other minority committers like Nikolay and Tomas already expressed doubts. Convince people like Pascaldragon and you might have a shot. Good luck, but as said, if Michael was sure of the acceptance of this avenue , he would have put the proposal before the committers immediately. Apparently he considers it a long shot, and the whole fpc-devel thread is an exercise in gaslighting to build his case with "popular support". As Trump and Elon prove, demagogy can get you anything. ---------------------------------------------------------------------- wpostma · 2026-04-21 01:22 Well maybe now 3.2.4 RC2 is imminent. Thanks to those making it so. ---------------------------------------------------------------------- dbannon · 2026-04-21 06:41 Hmm, can I please clarify here ?  Correct me if I am wrong. Marcov used to be the FPC Release Manager (history says a pretty good one too). At some point in time he decided he did not want that job. It does not matter why he so decided, he had every right to do so. Thats about it isn't it ?  Sure, Release has become a problem but maybe this discussion needs to be about the future, not the past ? Davo ---------------------------------------------------------------------- JuhaManninen · 2026-04-21 07:27 Quote from: dbannon on April 21, 2026, 08:41:56 amSure, Release has become a problem but maybe this discussion needs to be about the future, not the past ? I am happy it is moving forward. Yet I have been amazed by all the reasons about not having a release, which felt like lame excuses to me. See how Lazarus project does it. The human resources are equally limited. - First, developers themselves push their bug fix commits to fixes branch, or at least decide which commits are pushed. In SVN times there was a Wiki page where the commits were listed and then a middle man merged them. That was a useless extra step. A developer himself knows the best if his commit is a pure bug fix and should be merged. He must pay attention to the future fixes release while fixing bugs. - At some point there are enough commits and enough time have passed. An RC1 for a new release is built and announced for people to test. All developers try to make the release as stable and good as possible because they are responsible people. No special discipline or orders are needed. Users report their findings. They also want a stable and good release. RC2 is released, more bugs are fixed. Then RC3 ... typically that is enough and the actual release is built. There was nothing agonizing about this process. After fixing a bug it is super easy to merge. Users also love to help for a good release. - The build process itself is now done by Mattias and Martin for 3 major platforms: Windows, MaxOS and Linux (DEB + RPM). I admit I don't know how to do it. Maybe I should study it. There are scripts involved and the binaries are made rather quickly. Clearly building the binaries does not hinder the process. Now compare that to FPC release. So many artificial problems! For example the excuse that a timely release would be a "snapshot". OK, a well tested "snapshot" can be called a release. The RC1, RC2 etc. "snapshots" are part of the testing phase. That's what Lazarus project and most other open source SW projects do. Is a release totally bug free? Of course not. Now Lazarus project has 2100 open bug reports. Most of them will be still open when the next release comes out. ---------------------------------------------------------------------- dbannon · 2026-04-21 08:46 Yep, 100% agree Juha. Marco mentions that there is/are FPC Devs who commit only to main, not caring about Fixes. That seems to be a real problem and the reason, perhaps, that main is now so different. I would expect anyone with commit access would understand that Fixes and Release is the real target for any patches, main just a testing platform. But because its so long since that transition from Fixes to Release happened, no one think about it. Or its technically difficult because of that disparity. 'Someone' needs to remind committers of the need to target Fixes. But that will not solve the problem we have now. Now, its to get 3.2.4 out and, then, maybe, a new model consisting of a snapshot of main as a series of RC and a real release. And then strict rules about commits targeting the new Fixes. Wow, thats not going to be easy. Plenty of people here willing to help, most likely testing ... Davo ---------------------------------------------------------------------- Thaddy · 2026-04-21 09:02 Quote from: dbannon on April 21, 2026, 10:46:47 amYep, 100% agree Juha. Marco mentions that there is/are FPC Devs who commit only to main, not caring about Fixes. That seems to be a real problem and the reason, perhaps, that main is now so different.Have you been living under a tree? Of course all commits are against trunk. It is the task of a release manager to back-port candidates to a release candidate. Michael has just asked suggestions for that for 3.2.4 RC2 and the suggestions are many. Basically: one never commits to a RC unless approved by a release manager and done with his/hers permission or by him/herself. Even if you a core developer. Basic rule number one. ---------------------------------------------------------------------- marcov · 2026-04-21 09:31 A.s. the  discussion raging now everywhere should be how to accelerate FPC major branches, not optimise the shit out of a fixes release process that, while far from optimal, isn't a reason why you couldn't have releases twice an year. That is all detracting from the real problems. Most of the current discussions are by people that see the release gap as an easy ride to force through changes that they want because "it will fix the release process". But the proposals are light on details, and fix any counter with software/scripting that must still be written. Even if it accelerates the first major branch after current main (so the one after 3.4.0), the migration will at first have a delaying effect. I doubt users will really see a better product because of it before 2030. Ask yourself why after 4 years, the gitlab integration check only checks the compiler, and not the whole snapshot. The gitlab transition was managed by the same people.... Quote from: JuhaManninen on April 21, 2026, 09:27:17 amQuote from: dbannon on April 21, 2026, 08:41:56 amSure, Release has become a problem but maybe this discussion needs to be about the future, not the past ? I am happy it is moving forward. Yet I have been amazed by all the reasons about not having a release, which felt like lame excuses to me. See how Lazarus project does it. The human resources are equally limited. - First, developers themselves push their bug fix commits to fixes branch, or at least decide which commits are pushed. In SVN times there was a Wiki page where the commits were listed and then a middle man merged them. That was a useless extra step. A developer himself knows the best if his commit is a pure bug fix and should be merged. He must pay attention to the future fixes release while fixing bugs. That step was not useless, there were reasons for that. It was considered a good practice to first test fixes in main for a while, before merging (also think on effects on minor targets and compiler stability is very important) Trouble during merging was generally lower when done in original commit order in old branches (FIXES_3_2 is almost 8 years old!). In the beginning conflicts are easily resolved, but any manual intervention creates problems down the line. The older the fixes branch is, the bigger chance that some large rearrangement frequently causes problems. In Trunk, some commits changed arguments of hundreds, if not thousands of places from pchar to pansichar. Some additional big commits were about mass fixing Debian lint complaintsThe person doing the fix might not be aware of above differences between branches, specially major rearrangements. And then I'm not even talking about fundamental changes in the compiler. They are the biggest reason why only very few compiler changes are backported to fixesLower parts of the RTL are partially tied to the compilerAnd of course obviously there are dialect changes. What if trunk uses trunk features and you merge them back?I did a lot of merging in GIT post 3.2.2, and while git merge performance is slightly better than SVN (it gets not as often confused if there are massive changes in other parts of a file), it is not a game changer that matters for maintaining the fixes branch Why Lazarus used a wiki page instead of simply reviewing the list of eligible revisions, I don't know.  It was also possible with mantis (at least in FPC) to set the status of a bugreport as "tomerge", avoiding manual administration. All it required was the bugfixer to enter the revisions into the bugreport and set the status.  Easier with gitlab to link those, but not a real gamechanger. The point of this is that making fixes releases is not the problem, the core focus should be to accelerate FPC major branches to get to at least half the pace of Lazarus. But that means limits on when major features might be introduced and maybe a staging branch for such major features if they can't go into main yet. The developers don't like to talk about that, because that would mean constraints on their work, and a lot of thinking of releases outside the release cycle. They are much happier to talk about technology that will make all the release headaches magically go away (or at least postpone such constraints and obligations for a while). So the current discussions devolved into sprinkling gitlab magic on a process that was already not really a problem, with the convenient release gap as a stick to vilify the old process. But the fact is that everything for RC1 was merged, but Florian simply didn't formally announce it, and didn't follow it up with a release build, or allow post RC1 merges or reacting on release related mails.   And all of that process could have happened 1 year earlier too. The problem is not the process, but that people simply don't execute it. So those delays have nothing to with how release branches are prepared.   It is the last minute analysis "are we complete?", "is everything buildable?" and the "GO!" that followed it that simply wasn't done. As said usually that has a two times 6 week timeframe for a fixes release (6 wks RC1 and release, but sometimes either one can go faster if no issues are detected) . _IF_ executed. All these points are deliberately talked down to push forward to more gitlab usage by some vocal advocates. But those advocates point to use in companies and organisations with dedicated branch maintainers to do the grunt work. I really wonder if this will fly long term, specially since the proposals are very light on how it would actually work in practice, and scenarios for when problems come up. Since gitlab doesn't take decisions, it is only a lists keeper. Quote- The build process itself is now done by Mattias and Martin for 3 major platforms: Windows, MaxOS and Linux (DEB + RPM). I admit I don't know how to do it. Maybe I should study it. There are scripts involved and the binaries are made rather quickly. Clearly building the binaries does not hinder the process. In SVN times, a Windows release build takes about 2-3 minutes on a Ryzen 5700. Twice that for the x86 - x86_64  combi release (for hopefully obvious reasons). For windows, you do need an innosetup configuration, I assume it is the same for Lazarus.  OS X is a black art, but if I understood it right, adapting the constant flux of changes (newer releases, changes in packaging of tools needed for the build, making sure that the binaries are properly signed to pass gatekeeper) are the main complexity, not the build itself. For the GIT build of RC1 add another 5 minutes to get a proper export of the tree to build in.  I don't know how to do that with git (including submodules!), but that might be on me. FreeBSD roughly the same, maybe a bit slower due to the VMs lower I/O performance. QuoteNow compare that to FPC release. So many artificial problems! For example the excuse that a timely release would be a "snapshot". OK, a well tested "snapshot" can be called a release. You say they are artificial, but don't even know how Lazarus binaries are really made? Technically snapshots differ from releases : Snapshots are built daily, and are basically a toplevel "make all" in a tgz, so no additional work like innosetup, signing , no documentation, and a few other things.  Due to these lower they are somewhat easier to crosscompile on some leased Linux server.  In some cases there were multiple such snapshots for development versions (e.g. built with and without optimization). For releases the additional things (examples, documentation etc) are added,  build conditions are more fixed (-Ur, a certain level of optimization), and more additional packaging(innosetup, signing etc) For the rest it is just branch preparation, what to release. But for major releases that is the biggy. For fixes less so, and is usually resolved with a RC1, pretty much with anything sane merged, then a 6 week feedback period, and then the final release. Sometimes some build problems popup, usually OSX or iOS, but they are then resolved by giving the maintainer a few weekends time. So executed tightly (as done for e.g. 3.2.2), that means a 6-12 week release process, most of which is waiting for feedback. Do you now understand why I say that the fixes process is not the problem? QuoteThe RC1, RC2 etc. "snapshots" are part of the testing phase. That's what Lazarus project and most other open source SW projects do. Is a release totally bug free? Of course not. Now Lazarus project has 2100 open bug reports. Most of them will be still open when the next release comes out. It is not about _any_ bugs, but blocking bugs are more about things that limit an entire aspect of the compiler or new feature. This is specially one of the reasons for slow major branch turnover. One of the reasons it is this way is Lazarus. Lazarus had a tendency to skip FPC releases (FPC 3.2.0 was the first .0 compiler that was wholly used by Lazarus). You can't want a stable compiler for Lazarus, but at the same time say that we should use a more laissez fare approach about bugs, and say "pity, just wait for the next". That is a bit inconsistent  In addition to that, in FPC the RCs are both for feedback on blocker bugs, and to test the packaging. ---------------------------------------------------------------------- dbannon · 2026-04-21 09:37 Quote from: Thaddy on April 21, 2026, 11:02:49 amHave you been living under a tree? Yes, as a matter of fact I have been camped under a tree for the last week. A bush festival, displays of horse and dog skills, country music (both sorts). https://bushfestival.com.au QuoteOf course all commits are against trunk. It is the task of a release manager to back-port candidates to a release candidate. Firstly, I am suggesting that commits should be tested and adapted if necessary against FIXES, not an RC. And, maybe auto pushed to FIXES after a testing period. That way, fixes tracks main (with a delay) and the Release Manager's job is greatly eased. I have managed several projects with a model like that. Taking a snapshot of, or freezing main works too. (But I'd expect a lot of push back from the Devs.) A good example is the Debian Release model, that have a series of stages with increasing difficulty of making changes, and a hierarchy of change types. And Debian is a fairly big project Thaddy. Davo ---------------------------------------------------------------------- Thaddy · 2026-04-21 09:44 Well, that is actually close to what I proposed. The problem is that the release will be build against 3.2.3 and the patches do NOT apply to the RC, which if done correctly should be build against 3.2.3, not a frozen RC, if I was not clear. 3.2.3 is ahead of RC1, precisely because of that. I am quite sure that RC2 will be build against 3.2.3. ---------------------------------------------------------------------- 440bx · 2026-04-21 10:00 I want to thank @marcov for exposing some of the details related to the previous and current release process.  A rather welcome change from the tired "lack of manpower" thing. ---------------------------------------------------------------------- marcov · 2026-04-21 10:29 Quote from: dbannon on April 21, 2026, 11:37:16 amThat way, fixes tracks main (with a delay) and the Release Manager's job is greatly eased. I have managed several projects with a model like that. There is a bit of a responsibility issue. It changes the goal of the release manager of finding things to merge to make the release as good as possible, to what is spoon fed by the developers. So whatever happens, the eligible revisions list must remain. Btw, Debian is primarily a packaging project, not a software development process. They simply package something old and stable if a new release is not available. ---------------------------------------------------------------------- robert rozee · 2026-04-21 11:00 i posted to the fpc-devel list a suggestion on how to move forward : From rozee@****.***  Fri Apr 17 17:17:56 2026 [...] why not ask Claude to create a treatise detailing all the BUGS that it can identify through examining the source code differences between FPC 3.2.2 and the 4/5 years of subsequent code changes on GitLab? this would provide a blueprint of fixes that could be applied to create a short-term successor to the HIGHLY successful FPC 3.2.2. or it could be used as an errata document to warn [FPC 3.2.2] users of 'things to avoid'. one could also ask Claude to create a second treatise, detailing all the new FEATURES that have been added since FPC 3.2.2. this would then provide a blueprint to what enhancements could be considered for any future FPC 4. with Claude doing the majority of the work (and writing NO code) the main thing required to create these treatises would be a financial contribution from the FPC Foundation to fund Claude's efforts. NO DEVELOPER INPUT REQUIRED. could this be a way forward that no one would object to? while i applaud the efforts being made to get out an FPC 3.2.4 release using the existing tools available, i have reservations over the chances of success. comments, anyone? cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2026-04-21 11:12 Quote from: robert rozee on April 21, 2026, 01:00:43 pmcould this be a way forward that no one would object to? while i applaud the efforts being made to get out an FPC 3.2.4 release using the existing tools available, i have reservations over the chances of success. I don't see the point.  But anyway, I while I applaud using AI to get more insights, I think it should start small, and in parallel with normal efforts. Not directly in the way of critical processes.  Such long shots only eat resource (sparse foundation money and managers to instrument the AI, and interpret the results), delaying the release further. ---------------------------------------------------------------------- JuhaManninen · 2026-04-21 11:34 Quote from: Thaddy on April 21, 2026, 11:02:49 amBasically: one never commits to a RC unless approved by a release manager and done with his/hers permission or by him/herself. Even if you a core developer. Basic rule number one. That rule may be good in a commercial environment where a project's timeline and new features are strictly administered and well defined tasks are delegated to certain developers. It is not a good rule in an open source project where everybody scratches his own itch and there is no top-down design nor administrative hierarchy. In our open source projects the developer knows best if his commit is a bug fix or not. Yes, a commit should first be tested in trunk for some time but that also is flexible. A fix for a clear AV or memory leak typically does not need long testing. What would happen if I had to decide which commits from Zeljko's GTK3 improvements should be merged? Or from Martin's debugger improvements? It would be guess-work. The current process is light and has minimal overhead. If there is a merge conflict, I typically leave the commit out. It will be in the next major release which happens frequently enough so it is not a problem. Everybody is happy and time is saved for real productive tasks! ---------------------------------------------------------------------- Thaddy · 2026-04-21 11:41 That is not how I perceive current and historic practice for the releases: it seems the theory is followed pretty close. At least up until now and for the compiler itself. ---------------------------------------------------------------------- marcov · 2026-04-21 11:52 Quote from: Thaddy on April 21, 2026, 01:41:53 pmThat is not how I perceive current and historic practice for the releases: it seems the theory is followed pretty close. At least up until now and for the compiler itself. Juha doesn't seem to read any counter messages.  Anyway, even if you believe his oversimplifications, he himself says that first major releases need to be accelerated before you use that in a policy for minor releases. That's the whole cart-before-the-horse problem of the current discussion. It raves about main-> fixes, but says nothing about rotating main to fixes.  And while we can ignore the compiler and attached RTL( since they are complex, but are rarely merged to fixes now either), but the time also gives time to run a CI on umpteen platforms, including ones that are not part of a single centralized buildfarm (and e.g. have lower frequency). But anyway, the writing is on the wall. We go back to high tech version of pre 2.2.2 times, where releases are done without actually making an effort to have anything in them. The maintainer concludes that the committers haven't flagged anything(not flagging for merge out of caution, and then promptly forgetting about it), triggers the build, and the timed released is executed on schedule. (but essentially the same as the last, except for some high profile fixes). In the past, except the obvious delay of fixes reaching releases, that caused a whole lot of untested code to reach users only with the x.y.0 release, which was then promptly skipped by everybody, including Lazarus. However much more people nowadays use/test main, so it is not exactly the same situation. Back then only core + a few regular contributors used trunk/main. ---------------------------------------------------------------------- dbannon · 2026-04-21 11:59 Quote from: marcov on April 21, 2026, 12:29:32 pm.... It changes the goal of the release manager of finding things to merge to make the release as good as possible, to what is spoon fed by the developers. Yes, it does. After all the developer is the one who understands what the patch is for and how it works. QuoteDebian is primarily a packaging project, not a software development process. They simply package something old and stable if a new release is not available. Well, maybe. But they also manage an avalanche of requests from app developers (like me) who want to get the latest version into the next release. And they manage the conflicts and incompatibility that inevitably crop up. I guess my point is, the current system is apparently not working. We can keep doing the same thing, expect the same result. Or consider change. Fortunately, its not up to me to choose. Davo ---------------------------------------------------------------------- marcov · 2026-04-21 12:02 Quote from: dbannon on April 21, 2026, 01:59:01 pmI guess my point is, the current system is apparently not working. We can keep doing the same thing, expect the same result. Or consider change. Fortunately, its not up to me to choose. That is my whole point. That is just not true. It is not executed, so how could you know if it works?  With whatever system, if no work is done, nothing happens. Are therefore all systems bad? No. The current process worked fine for more than a decade, and there is nothing fundamentally wrong with it that it could not support 2 fixes releases per year. With the original care and everything. I still think Debian is a bad match for comparisons. But obviously they have more workers interested in releasing. That is the difference, not the process. ---------------------------------------------------------------------- 440bx · 2026-04-21 12:17 Quote from: marcov on April 21, 2026, 02:02:27 pmThe current process worked fine for more than a decade, and there is nothing fundamentally wrong with it that it could not support 2 fixes releases per year. With the original care and everything. Wait... from what I've understood, the current process isn't the same as the previous process, specifically, the software used to manage the releases isn't the same and the release manager also isn't the same. Those changes likely imply other changes in the process that are not obvious but there nonetheless.  We all see the result: 5 years without a release and I believe that's what we all want to avoid in the future. I think @Juha has a point.  FPC is a large and varied project.  Even someone who is very well versed in compiler development is unlikely to be an expert in every platform FPC supports, including the different code generators, optimizers and linkers required for different platforms.  This implies that whoever is managing the global project has to delegate responsibilities to other members to ensure those parts of the project keep advancing and make it into the next release in a timely basis. Quite likely my perception is overly simple but, it seems to me that, at this point, the current release manager is part of the problem. ---------------------------------------------------------------------- robert rozee · 2026-04-21 12:24 Quote from: marcov on April 21, 2026, 01:52:14 pm[...] much more people nowadays use/test main [...] [whereas in the past] only core + a few regular contributors used trunk/main. on what evidence do you base the assertion that "much more people nowadays use/test main". the Lazarus website links to SourceForge for downloads, where FPC 3.2.2 is the most recent version hosted. likewise, freepascal.org provides links only (as far as i could see) to FPC 3.2.2. according to google, "As of early 2026, the Lazarus IDE has well over four million total downloads from SourceForge", while regarding FPC, google says that, "SourceForge frequently highlights that the [FPC] project has exceeded over 100,000 total downloads". the above suggests to me that: 1. FPC is far more often used with Lazarus than on its own, and, 2. of the folks using FPC (with or without Lazarus), the vast majority are using FPC 3.2.2. do you have any concrete numbers for how many people use test/main/trunk? cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2026-04-21 12:37 Quote from: 440bx on April 21, 2026, 02:17:35 pmQuote from: marcov on April 21, 2026, 02:02:27 pmThe current process worked fine for more than a decade, and there is nothing fundamentally wrong with it that it could not support 2 fixes releases per year. With the original care and everything. Wait... from what I've understood, the current process isn't the same as the previous process, specifically, the software used to manage the releases isn't the same and the release manager also isn't the same. This cycle had to adjust to GIT, and that caused many delays, but the essence remains the same. But the migration could also have been handled much faster. And there was no reason to hold the fixes branch over an year in freeze if you don't initiate anything to make a final release. QuoteThose changes likely imply other changes in the process that are not obvious but there nonetheless.  We all see the result: 5 years without a release and I believe that's what we all want to avoid in the future. If you really want to see the cause in the process no matter what yes. But I'm telling you, that is not it. It is the people. They get older, have less free time, and prefer to spend time on fun things rather than thinking of releases.  The new release manager avoids conflict, so didn't force people to do their thing now, or forget about it,  and presto, a 5 year gap. QuoteI think @Juha has a point.  FPC is a large and varied project.  Even someone who is very well versed in compiler development is unlikely to be an expert in every platform FPC supports, including the different code generators, optimizers and linkers required for different platforms.  As said, the compiler is not merged via common procedures anyway after the .0 release. Between branching a new fixes branch and the .0 release, there is a lot of main-> fixes merging that is relatively straightforward, but after that less and less, as simply the class/datastructure of the compiler changes, needing a real will to migrate changes. QuoteThis implies that whoever is managing the global project has to delegate responsibilities to other members to ensure those parts of the project keep advancing and make it into the next release in a timely basis. Delegating also means following up if that doesn't happen, and having process in place for that. And that is where the problems of such approach lie.  In companies and high profile open source project with dedicated release people and/or even paid workers that simply means rotate to the next grunt to do the work and a negative recommendation. What do you do in the future if a committer hardly merges up front, and if you talk to him about it he says "safety" and says he will look at it the weekend after next ?  Read all the mails of Michael and Graeme c.s., and see what alternate procedures they describe except for the "flag for merge at the moment" and the "release manager that dutifully and automatically presses the button when prompted". They don't even commit to maintaining an eligible revision list, making falling back to the current process in the case of problems, or simply to mop up revisions that were wrong. Sometimes when asked, they all postpone that to the future and scripting and the like. Just like they did with the gitlab migration, but it took over 1.5 years to get basic cherry-picking with a list of merged revisions available. By the time such things are sorted, the new fixes branch will already be old.  And even if the support still must be written, you could outline things way more detailed. QuoteQuite likely my perception is overly simple but, it seems to me that, at this point, the current release manager is part of the problem. Certainly. But it is carrying out the tasks, not the tasklist that is the problem. ---------------------------------------------------------------------- marcov · 2026-04-21 12:41 Quote from: robert rozee on April 21, 2026, 02:24:50 pmdo you have any concrete numbers for how many people use test/main/trunk? Just my gut feeling from anecdotal evidence on maillist and bugtrackers.  Most relevant users that submit detailed bugreports and the like won't use a pre built snapshot, as they would require a FPC compiled with debuginfo.   To debug, and get traces etc. No Lazarus build provides that at the moment. Rightfully so, because such builds are a pain to use daily, tracing into any language helper. Lazarus could help by doing what Delphi does, having a tree with and without debuginfo, and maybe even more gradations inbetween (like anything but system/objpas/sysutils/classes without debugging). I talked to MartinFr about it, and he is working on a system to let the debugger only enter a function/procedure if the unit is on a list, but that will take a while. ---------------------------------------------------------------------- 440bx · 2026-04-21 12:47 @marcov, thank you for the details. ---------------------------------------------------------------------- Martin_fr · 2026-04-21 12:54 Quote from: marcov on April 21, 2026, 02:41:26 pmI talked to MartinFr about it, and he is working on a system to let the debugger only enter a function/procedure if the unit is on a list, but that will take a while. Actually that is in 4.99. (mainly for FpDebug, but in limited versions also gdb and lldb).  It works great for all the fpc_check_object, fpc_ansi_assign, .... It is NOT based on packages though. You need the names of the function or files. (IIRC, at least fpdebug sees the full path, so you could use parts of the path / but don't recall if I tested that). (that is a once off, 2nd time you change between debug and release compiler will be handled by the IDE) And the IDE 4.99 now also deals with the wrong full path of a pre- build debug FPC. It just requires the user to do a manual rebuild of his project (and LCL/etc packages), or it will fail "ppu changed". ---------------------------------------------------------------------- dbannon · 2026-04-21 13:19 Quote from: marcov on April 21, 2026, 02:02:27 pmI still think Debian is a bad match for comparisons. But obviously they have more workers interested in releasing. That is the difference, not the process. Yes. The process is not happening simply because key people do not see it as a high enough priority. Thanks Marcov, I think we understand now. Davo ---------------------------------------------------------------------- marcov · 2026-04-21 13:26 Quote from: dbannon on April 21, 2026, 03:19:13 pmYes. The process is not happening simply because key people do not see it as a high enough priority. Thanks Marcov, I think we understand now. And force through major changes without either being ready, or having contingencies. See e.g. last comment of Michael https://gitlab.com/freepascal.org/fpc/source/-/work_items/41735 Basically they are going to ruin the eligible version registration in a last ditch effort. ---------------------------------------------------------------------- Thaddy · 2026-04-21 13:34 @Marcov As long as the tests pass, that is. I would do the same... Then it is a second to last ditch. Btw, my debug builds are also not daily, but current is, so I am cheating myself, I know. I do a debug build only when I am out of wit. ---------------------------------------------------------------------- Thausand · 2026-04-21 13:35 Quote from: marcov on April 21, 2026, 03:26:25 pmBasically they are going to ruin the eligible version registration in a last ditch effort. I not understand why you have write this and other message again.. again ... again... for people not know please have read all discussion not state only opinion and not have real answer. If want opinion, then I make also: If some one is think I make spend more time motivate why my work is need for eligible after > 4 year then better have think again. That is why exist commit message -> so take time and read what is motivate. ---------------------------------------------------------------------- Thaddy · 2026-04-21 13:37 Marco has experience as release manager, just you forgot... ---------------------------------------------------------------------- marcov · 2026-04-21 13:39 Quote from: Thausand on April 21, 2026, 03:35:35 pmIf want opinion, then I make also: If some one is think I make spend more time motivate why my work is need for eligible after > 4 year then better have think again. That is why exist commit message -> so take time and read what is motivate. How will you track what is already merged to fixes or not for the last 1.5 years that still need to be done for 3.2.4? Anyway, it seems that at least Florian is merging via the -x mechanism. There is no history for main->fixes in the gitlab environment. The proposal (no matter what you think of it) is to build such thing based on MRs for the new major branch, but that is not even definitive, and doing it for fixes is burning bridges. (including 3.2.6 if the major branch delays more than expected) I understand that if you are on trunk, you probably don't care, but many people will use 3.2.4. ---------------------------------------------------------------------- Martin_fr · 2026-04-21 14:00 Quote from: marcov on April 21, 2026, 03:39:13 pmHow will you track what is already merged to fixes There are indeed some commits without the "cherry picked from". Seems so that in the latest commits, all parties have that set. That said, I don't know how that works with older merges, that may be done with tooling in mind that uses other means, and if it allows to easily find a complete set. --- **IF** you don't have conflicts, then you can usually use "git cherry" => it will find commits that don't have a matching commit (by changeset). But when you have conflicts, and had to edit the merges... Its not the same as svn, that had a "database" like list of actual merged revisions (which allowed adding numbers if automation failed). ---------------------------------------------------------------------- Thausand · 2026-04-21 14:04 I not forget Thaddy  It never a problem. Now I read ML and issues and all talk other people make. Because I know marco is RM for past then I not understand why is question his experience. Quote from: marcov on April 21, 2026, 03:39:13 pmHow will you track what is already merged to fixes or not for the last 1.5 years that still need to be done for 3.2.4? Because they on you mergelist QuoteAnyway, it seems that at least Florian is merging via the -x mechanism. There is no history for main->fixes in the gitlab environment. The proposal (no matter what you think of it) is to build such thing based on MRs for the new major branch, but that is not even definitive, and doing it for fixes is burning bridges. (including 3.2.6 if the major branch delays more than expected) I make understand that not all change is worse. But lack understanding and motivation is imho no good. I not have any say for Florian but I read proposal from other and they have make no sense in positive way for me. Only motivate is look like 'ship it" any way and push  burden for person who is make commit. This ok when make change intrusive and have take responsibility but not for not do any thing 4 year and now tell person who commit for have motivate why commit is might need eligbile for new release. It > 4 year and I not know what I have eat when breakfast 4 year ago, you have ?  QuoteI understand that if you are on trunk, you probably don't care, but many people will use 3.2.4. I have personal no care because yes I make use trunk. But trunk is contain fixes that is need for make target for new compiler. End user is not know how apply fixes then rebuild compiler. So every time when fix not merged is mean wait next release and have cross finger it is merge. It is make 2 cycle release for have final fix for end user. More easy is have release for self and have forget all drama. ---------------------------------------------------------------------- wpostma · 2026-04-21 14:51 This project is widely considered "dead" by most people on the internet because of no actual release for five and a half years. The nightly builds are so well hidden (there's NO link to them from the download page), and everything on the wiki is 30 years old. But yeah, the problem is a simple matter.    It's not simple. ---------------------------------------------------------------------- marcov · 2026-04-21 14:55 Quote from: wpostma on April 21, 2026, 04:51:16 pmThis project is widely considered "dead" by most people on the internet Well, then we are Delphi compatible in that aspect :-) ---------------------------------------------------------------------- Thausand · 2026-04-21 14:55 Quote from: wpostma on April 21, 2026, 04:51:16 pmThe nightly builds are so well hidden (there's NO link to them from the download page), and everything on the wiki is 30 years old. https://www.freepascal.org/develop.html ---------------------------------------------------------------------- Thaddy · 2026-04-21 15:14 Quote from: wpostma on April 21, 2026, 04:51:16 pmThis project is widely considered "dead" by most people on the internet because of no actual release for five and a half years.It is still within four years until almost four  weeks: 20'th of May 2021. And you forget about activity. Debian contains code that is over 20 tears old for some processor families.. Why would they do that? It is only considered "dead" for people that do not know. You may consider yourself what kind of animal I should address you with. Working code is never dead. It works... To help you a little: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i // full program{$mode objfpc}{$apptype console}uses dateutils, sysutils;  function Age(Releasedate:string):integer;inline;  begin    Result := YearsBetween(Now,StrToDateTime(Releasedate));  end;begin  // the Age routine takes the defaultformatsettings.  writeln(Age('20-05-2021'));  readln;  end...... You are way off, this says 4 at the moment, at least 7 months. By then your toddler walks.. ---------------------------------------------------------------------- Fred vS · 2026-04-21 15:35 Quote from: marcov on April 21, 2026, 02:37:04 pmRead all the mails of Michael and Graeme c.s., and see what alternate procedures they describe except for the "flag for merge at the moment" and the "release manager that dutifully and automatically presses the button when prompted". They don't even commit to maintaining an eligible revision list, making falling back to the current process in the case of problems, or simply to mop up revisions that were wrong. Nevertheless, they are proposing something concrete. https://gitlab.com/freepascal.org/fpc/source/-/work_items/41735 And that gets things moving, unlike the empty talk and excuses we're used to hearing. ---------------------------------------------------------------------- Thaddy · 2026-04-21 15:45 Empty? Scrap that, it is impatience by others. Outside pressure seems to help in this case, but is frankly a gotspe. I like it the old ways: it is done when it is done, instead of our commercial cousin that calls a bugfix or two a major release...On all their three platforms they support..) Perspective Fred, this is all about psychology, nothing else. A release adds nothing to a user experience if it is not done properly. I am ashamed about the community pushing for something that is in effect just a name, nothing more, nothing less. I would simply call RC1 a release to shut them up. And then the lot starts compaining it is rubbish and again the major platforms are advantaged at the cost of others... Yeah, right. What is the prescription for your glasses?  (Certainly if you push for a niche platform, plz help out) And I am now playing "I hate to say I told you so" by the Hives again. There is a gross limitation on respect by many of you. Or utter and complete lack of brains.            Go ahead and use the unleashed branch: good luck with the minor platforms... ---------------------------------------------------------------------- Fred vS · 2026-04-21 16:02 Quote from: Thaddy on April 21, 2026, 05:45:01 pmYeah, right. What is the prescription for your glasses?  My reading glasses? No prescription, I tried them on right there in a Chinese shop; They're 2.5x magnification and cost me 3 euros. And I can perfectly read all your unnecessary ad hominem attacks. Quote from: Thaddy on April 21, 2026, 05:45:01 pmThere is a gross limitation on respect by many of you. Where is the lack of respect? Respect must be mutual, towards users as well. ---------------------------------------------------------------------- Thaddy · 2026-04-21 16:09 Quote from: Fred vS on April 21, 2026, 06:02:48 pmRespect must be mutual, towards users as well. Respect to us users has over the years been shown by many of the core team, as well as patience in handling silly requests for an early release. Just in case you missed that. Not very high on my Einstein ranking. (On which I score also average otherwise) ---------------------------------------------------------------------- valdir.marcos · 2026-04-22 03:36 Quote from: Thaddy on April 21, 2026, 06:09:54 pmQuote from: Fred vS on April 21, 2026, 06:02:48 pmRespect must be mutual, towards users as well.Respect to us users has over the years been shown by many of the core team, as well as patience in handling silly requests for an early release. Just in case you missed that. Not very high on my Einstein ranking. (On which I score also average otherwise) Status of FPC 3.4.0 or FPC 4.0.0 [major release] https://forum.lazarus.freepascal.org/index.php/topic,73355.0.html FPC 3.2.0 [major release] was released on June 20, 2020. That's 5 years and 10 months ago. FPC 3.2.2 [minor release] was released on May 21, 2021. That's 4 years and 11 months ago. Are you serious, Thaddy? "Silly requests for an early release"?  Have you been living under a tree? You are barking up the wrong tree, again! ---------------------------------------------------------------------- MarkMLl · 2026-04-22 06:39 Quote from: Fred vS on April 21, 2026, 06:02:48 pmQuote from: Thaddy on April 21, 2026, 05:45:01 pmThere is a gross limitation on respect by many of you. Where is the lack of respect? Respect must be mutual, towards users as well. While I disagree with those who argue that because there has not been a new release for several years it will impact the credibility of Pascal, it does have to be said that it is fairly common for somebody to say something like "Use generics for that... oops, you'll have to use trunk". It's also fairly common for somebody to say "Yes, there's problems with the documentation and in particular the indexing but they're fixed in trunk". And the person who is most likely to do that is Thaddy. MarkMLl ---------------------------------------------------------------------- Thaddy · 2026-04-22 06:55 Well, if I see something I could do I would certainly help. Even making coffee or pancakes. I have time on my hands. My point is I find people moaning where that is not due. Alas that is also quite common. But it is an opinion. ---------------------------------------------------------------------- 440bx · 2026-04-22 07:03 Quote from: MarkMLl on April 22, 2026, 08:39:25 amWhile I disagree with those who argue that because there has not been a new release for several years it will impact the credibility of Pascal, How can it not ?... the great majority of "living" programming languages in the PC landscape see at least and, I really mean at least, one release in 5 years (and that would already be considered exceptionally long and unusual.)   In the majority of cases, a programming language that has not seen an update in 5 years is a dead language. Unfortunately and sadly, I think the long delay between v3.2.2 and v3.2.4 reflects very poorly on FPC.  It's difficult to convince a potential newcomer to the language that the language isn't dead. ---------------------------------------------------------------------- marcov · 2026-04-22 09:40 I have gotten a green light to start merging again. The first batch is already done (the older regexpr package revs). Expect more in the coming days. ---------------------------------------------------------------------- Fred vS · 2026-04-22 09:47 Quote from: marcov on April 22, 2026, 11:40:25 amI have gotten a green light to start merging again. The first batch is already done (the older regexpr package revs). Expect more in the coming days. Great. If you have the time and energy, could you take a look at the tons of fixes made by Pierre Muller (for OpenBSD among others)? Thanks and peace. ---------------------------------------------------------------------- marcov · 2026-04-22 10:28 Quote from: Fred vS on April 22, 2026, 11:47:41 amGreat. If you have the time and energy, could you take a look at the tons of fixes made by Pierre Muller (for OpenBSD among others)? Too generic. But I have looked at rtl/openbsd and most seems to be merged, except for a few that I merged now. I had one t_bsd related openbsd fix on my list and mentioned it to Florian. Probably the t_ and i_ files will have to be checked using logs or diff since  I don't track/split out compiler revisions for the most, so sb else has to do that. It would help tremendously, if you simply try to build and compile some test programs with fixes_3_2 in your openbsd setup.  The merge window is still at least two weeks, so there is time for such things. ---------------------------------------------------------------------- Fred vS · 2026-04-22 11:04 Quote from: marcov on April 22, 2026, 12:28:29 pmToo generic. Yes, sorry, Pierre did fixes for many BSD OS, DragonFly included. Quote from: marcov on April 22, 2026, 12:28:29 pmIt would help tremendously, if you simply try to build and compile some test programs with fixes_3_2 in your openbsd setup. With pleasure. I will compile fpc fixes_3_2 on OpenBSD 7.4, 7.5, 7.6, 7.7 and 7.8. and try it with some tests programs. If something goes wrong, I will add a post there: https://gitlab.com/freepascal.org/fpc/source/-/work_items/41017 ---------------------------------------------------------------------- Fred vS · 2026-04-22 15:46 Quote from: marcov on April 22, 2026, 12:28:29 pmIt would help tremendously, if you simply try to build and compile some test programs with fixes_3_2 in your openbsd setup. Sadly it is not yet ok, see last posts: https://gitlab.com/freepascal.org/fpc/source/-/work_items/41017 ---------------------------------------------------------------------- BSaidus · 2026-04-22 16:59 @marcov Please if you can merge the 38188 patch for fixing OpenBSD socket bind problem. https://gitlab.com/freepascal.org/fpc/source/- /work_items?sort=created_date&state=all&search=38188&first_page_size=2 0&show=eyJpaWQiOiIzODE4OCIsImZ1bGxfcGF0aCI6ImZyZWVwYXNjYWwub3JnL2ZwYy9 zb3VyY2UiLCJpZCI6OTE1NTYzMTZ9 Thank you in advance. ---------------------------------------------------------------------- Fred vS · 2026-04-22 20:36 Maybe important for next release. In the MakeFile update: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i REQUIREDVERSION=3.2.2 With something that allows to use also fpc 3.2.4. Pseudo code (sorry I dont know how to use it in MakeFile): Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i REQUIREDVERSION=3.2.2 or 3.2.4 ---------------------------------------------------------------------- marcov · 2026-04-22 20:37 Quote from: BSaidus on April 22, 2026, 06:59:35 pm@marcov Please if you can merge the 38188 patch for fixing OpenBSD socket bind problem. https://gitlab.com/freepascal.org/fpc/source/- /work_items?sort=created_date&state=all&search=38188&first_page_size=2 0&show=eyJpaWQiOiIzODE4OCIsImZ1bGxfcGF0aCI6ImZyZWVwYXNjYWwub3JnL2ZwYy9 zb3VyY2UiLCJpZCI6OTE1NTYzMTZ9 Done. Had a conflict that I couldn't resolve ( by commiting other files earlier), had to manually circumvent. ---------------------------------------------------------------------- marcov · 2026-04-22 20:39 Quote from: Fred vS on April 22, 2026, 10:36:09 pmCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i REQUIREDVERSION=3.2.2 With something that allows to use also fpc 3.2.4. I assume you mean the makefile in trunk? This check supports two versions, the other is REQUIREDVERSION2, which is now 3.2.0 When 3.2.4 is final, the 3.2.0 version will become 3.2.4 etc. ---------------------------------------------------------------------- BSaidus · 2026-04-22 20:56 Quote from: marcov on April 22, 2026, 10:37:09 pmQuote from: BSaidus on April 22, 2026, 06:59:35 pm@marcov Please if you can merge the 38188 patch for fixing OpenBSD socket bind problem. https://gitlab.com/freepascal.org/fpc/source/- /work_items?sort=created_date&state=all&search=38188&first_page_size=2 0&show=eyJpaWQiOiIzODE4OCIsImZ1bGxfcGF0aCI6ImZyZWVwYXNjYWwub3JnL2ZwYy9 zb3VyY2UiLCJpZCI6OTE1NTYzMTZ9 Done. Had a conflict that I couldn't resolve ( by commiting other files earlier), had to manually circumvent. Thanks @marcov You are the best ---------------------------------------------------------------------- Fred vS · 2026-04-22 21:00 Quote from: BSaidus on April 22, 2026, 10:56:24 pmQuote from: marcov on April 22, 2026, 10:37:09 pmQuote from: BSaidus on April 22, 2026, 06:59:35 pm@marcov Please if you can merge the 38188 patch for fixing OpenBSD socket bind problem. https://gitlab.com/freepascal.org/fpc/source/- /work_items?sort=created_date&state=all&search=38188&first_page_size=2 0&show=eyJpaWQiOiIzODE4OCIsImZ1bGxfcGF0aCI6ImZyZWVwYXNjYWwub3JnL2ZwYy9 zb3VyY2UiLCJpZCI6OTE1NTYzMTZ9 Done. Had a conflict that I couldn't resolve ( by commiting other files earlier), had to manually circumvent. Thanks @marcov You are the best Sure but OpenBSD with last commits is not yet working on a real OpenBSD machine (did you try to compile fpc himself?). ---------------------------------------------------------------------- Fred vS · 2026-04-22 21:00 Quote from: marcov on April 22, 2026, 10:39:20 pmQuote from: Fred vS on April 22, 2026, 10:36:09 pmCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i REQUIREDVERSION=3.2.2 With something that allows to use also fpc 3.2.4. I assume you mean the makefile in trunk? This check supports two versions, the other is REQUIREDVERSION2, which is now 3.2.0 When 3.2.4 is final, the 3.2.0 version will become 3.2.4 etc. No the one in branch fpc_3.2._fixes: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i override PACKAGE_NAME=fpcoverride PACKAGE_VERSION=3.2.3REQUIREDVERSION=3.2.2REQUIREDVERSION2=3.2.0 If I want to compile fpc_3.2._fixes on a real OpenBSD machine, if I use a previously compiled from a release_3_2_4-branch. The same if I want to re-compile with the fpc 3.2.3 produced, there is  error because the bootstrap compiler is not 3.2.2. ---------------------------------------------------------------------- BSaidus · 2026-04-22 22:04 Quote from: Fred vS on April 22, 2026, 11:00:35 pmQuote from: BSaidus on April 22, 2026, 10:56:24 pmQuote from: marcov on April 22, 2026, 10:37:09 pmQuote from: BSaidus on April 22, 2026, 06:59:35 pm@marcov Please if you can merge the 38188 patch for fixing OpenBSD socket bind problem. https://gitlab.com/freepascal.org/fpc/source/- /work_items?sort=created_date&state=all&search=38188&first_page_size=2 0&show=eyJpaWQiOiIzODE4OCIsImZ1bGxfcGF0aCI6ImZyZWVwYXNjYWwub3JnL2ZwYy9 zb3VyY2UiLCJpZCI6OTE1NTYzMTZ9 Done. Had a conflict that I couldn't resolve ( by commiting other files earlier), had to manually circumvent. Thanks @marcov You are the best Sure but OpenBSD with last commits is not yet working on a real OpenBSD machine (did you try to compile fpc himself?). Hi @Fred Vs, Did not yet, but I will try to do my best to compile it this week end & feedback community with results. ---------------------------------------------------------------------- Fred vS · 2026-04-22 22:20 Quote from: BSaidus on April 23, 2026, 12:04:41 amHi @Fred Vs, Did not yet, but I will try to do my best to compile it this week end & feedback community with results. Oh, that would be great, I feel so lonely. :'( ---------------------------------------------------------------------- DonAlfredo · 2026-04-23 05:58 I will (also) help ... ;-) ---------------------------------------------------------------------- Fred vS · 2026-04-23 09:25 Quote from: DonAlfredo on April 23, 2026, 07:58:29 amI will (also) help ... ;-) Many thanks Alfred (and YOU are the one and only true best). ---------------------------------------------------------------------- marcov · 2026-04-23 09:35 Quote from: Fred vS on April 22, 2026, 11:00:56 pmNo the one in branch fpc_3.2._fixes: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i override PACKAGE_NAME=fpcoverride PACKAGE_VERSION=3.2.3REQUIREDVERSION=3.2.2REQUIREDVERSION2=3.2.0 If I want to compile fpc_3.2._fixes on a real OpenBSD machine, if I use a previously compiled from a release_3_2_4-branch. The same if I want to re-compile with the fpc 3.2.3 produced, there is  error because the bootstrap compiler is not 3.2.2. I think that is normal. Bootstrap a release with two previous releases, the fixes versions will be moved also after 3.2.4 is released. Note you can pass OVERRIDEVERSIONCHECK=1 to override for special cases, like not have a formal bootstrap version available. (as is often done for new targets). ---------------------------------------------------------------------- Fred vS · 2026-04-23 10:09 Quote from: marcov on April 23, 2026, 11:35:52 amNote you can pass OVERRIDEVERSIONCHECK=1 to override for special cases, Yes thanks but I know that. And I pray that one day you will stop systematically opposing everything I propose. The OpenBSD saga was exhausting because of your lack of openness. ---------------------------------------------------------------------- MarkMLl · 2026-04-24 07:04 Quote from: Fred vS on April 23, 2026, 12:09:14 pmQuote from: marcov on April 23, 2026, 11:35:52 amNote you can pass OVERRIDEVERSIONCHECK=1 to override for special cases, Yes thanks but I know that. And I pray that one day you will stop systematically opposing everything I propose. The OpenBSD saga was exhausting because of your lack of openness. I suggest that that also needs to automatically accept recompilation with the current version, not just the previous one. A specific example was the situation when Debian's linker (?) behaviour changed between v12 and v13: a download of the FPC binary release (from the FPC repo) was unable to recompile itself without tweaking the makefile. I mentioned it at the time and was effectively told to go away and stop being stupid. MarkMLl ---------------------------------------------------------------------- Thaddy · 2026-04-24 07:20 Quote from: MarkMLl on April 24, 2026, 09:04:50 amI suggest that that also needs to automatically accept recompilation with the current version, not just the previous one. Not possible: The bootstrap may or may not rely on features that are only present or differently implemented in the correct Bootstrap compiler and that happens in practice. Not often, but it happens. Like this one between 3.0.X and 3.1.1: https://wiki.lazarus.freepascal.org/User_Changes_3.2.0#Class_reference s_in_a_class_VMT's_field_table That is why the core developers always warn against it, discourage its use. (Jonas put me right years ago) But for lack of a bootstrap compiler of the right release, it is an alternative that often, but not always, works. It happened to me just this week, forcing me to build a 3.2.2. Many user changes that affect the compiler lead to a failed build when using OVERRIDEVERSIONCHECK=1; For the same reason the bootstrap compiler must be of the previous release version - the patch number should not matter - and must not be older. ---------------------------------------------------------------------- marcov · 2026-04-24 09:53 Quote from: MarkMLl on April 24, 2026, 09:04:50 amI suggest that that also needs to automatically accept recompilation with the current version, not just the previous one. A specific example was the situation when Debian's linker (?) behaviour changed between v12 and v13: a download of the FPC binary release (from the FPC repo) was unable to recompile itself without tweaking the makefile. I mentioned it at the time and was effectively told to go away and stop being stupid. I probably told you then what I'm telling you now, that you don't have to modify the makefile, as that is what the override switch is for. ---------------------------------------------------------------------- robert rozee · 2026-04-24 13:43 Quote from: Thaddy on April 24, 2026, 09:20:08 amThe bootstrap may or may not rely on features that are only present or differently implemented in the correct Bootstrap compiler and that happens in practice. Not often, but it happens. hi Thaddy,     i'm a little confused here. are you saying that a given version of FPC may not necessarily be able to rebuild itself? for instance, i am using FPC 3.2.2 under Linux. i frequently use this FPC 3.2.2 to rebuild itself, by running (with sudo) a shell script containing: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i #!/bin/shCOMPILER=fpcmake cleanmake all FPC=$COMPILER OPT="-Fl/usr/local/lib"make FPC=$COMPILER install INSTALL_PREFIX=/usr/ ... and my assumption has always been that any release version of FPC is capable of rebuilding itself. btw: i have always thought it rather silly that FPC was not (from the very start) written using just a subset of the language, such that any version of FPC should be able to build any other version. cheers, rob   :-) ---------------------------------------------------------------------- Thaddy · 2026-04-24 14:39 No Rob. It is rare, but failures can occur as I explained. I also gave an example where it failed. And, Yes, Rob, now it gets confusing: Yes, the compiler can rebuild itself but after bootstrapping initially: As can be seen from: Bootstrap compiler builds ppo1 - at that point the compiler is good - that builds ppo2 that builds ppo3: ppo1 is already a compiler from the version you want to build, only not yet optimized with WPO. So if you want to build a maiden compiler from source, you will need a bootstrap compiler from one version earlier. Get it? After ppo1 is finished the compiler can rebuild itself. Proof is the wpo cycle. (wpo stands for Whole Program Optimization, just in case) The compiler makefile.fpc and makefile, not the root makefiles, contains the information you need to know. ---------------------------------------------------------------------- Fred vS · 2026-04-24 14:45 Excellent news: fpc for OpenBSD is on the road again.  https://gitlab.com/freepascal.org/fpc/source/-/work_items/41017 ---------------------------------------------------------------------- PascalDragon · 2026-04-25 15:50 Quote from: Fred vS on April 23, 2026, 12:09:14 pmAnd I pray that one day you will stop systematically opposing everything I propose. The OpenBSD saga was exhausting because of your lack of openness. And I pray that one day you'll stop complaining about things that are done a certain way for reasons... Quote from: MarkMLl on April 24, 2026, 09:04:50 amI suggest that that also needs to automatically accept recompilation with the current version, not just the previous one. We don't allow that precisely to avoid people trying to compile a current 3.3.1 with an older 3.3.1 which had been regular support questions before the version check despite us saying that we only support compiling with the current official release (and the one before that). The version check can't a more granular check because the revision might have been stripped. ---------------------------------------------------------------------- Fred vS · 2026-04-25 17:44 Quote from: PascalDragon on April 25, 2026, 05:50:01 pmQuote from: MarkMLl on April 24, 2026, 09:04:50 amI suggest that that also needs to automatically accept recompilation with the current version, not just the previous one. We don't allow that precisely to avoid people trying to compile a current 3.3.1 with an older 3.3.1 which had been regular support questions before the version check despite us saying that we only support compiling with the current official release (and the one before that). The version check can't a more granular check because the revision might have been stripped. In case you missed the reason of the proposal, it concerned the next version of fpc 3.2.4, and never version 3.3.1. ---------------------------------------------------------------------- robert rozee · 2026-04-25 18:16 Quote from: PascalDragon on April 25, 2026, 05:50:01 pmWe don't allow that precisely to avoid people trying to compile a current 3.3.1 with an older 3.3.1 which had been regular support questions before the version check despite us saying that we only support compiling with the current official release (and the one before that). The version check can't a more granular check because the revision might have been stripped. "which had been regular support questions before": would you mind rewording that paragraph in clear English please? i think understanding what you are trying to say here may be important, but you have mangled the language enough to make it ambiguous. cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2026-04-25 18:39 Quote from: Fred vS on April 25, 2026, 07:44:43 pmIn case you missed the reason of the proposal, it concerned the next version of fpc 3.2.4, and never version 3.3.1. There is no reason(ing) in that post, only a request. ---------------------------------------------------------------------- Fred vS · 2026-04-25 19:03 Quote from: marcov on April 25, 2026, 08:39:43 pmQuote from: Fred vS on April 25, 2026, 07:44:43 pmIn case you missed the reason of the proposal, it concerned the next version of fpc 3.2.4, and never version 3.3.1. There is no reason(ing) in that post, only a request. Obviously, I haven't prayed enough.  :'( ---------------------------------------------------------------------- PascalDragon · 2026-04-27 19:46 Quote from: robert rozee on April 25, 2026, 08:16:36 pmQuote from: PascalDragon on April 25, 2026, 05:50:01 pmWe don't allow that precisely to avoid people trying to compile a current 3.3.1 with an older 3.3.1 which had been regular support questions before the version check despite us saying that we only support compiling with the current official release (and the one before that). The version check can't a more granular check because the revision might have been stripped. "which had been regular support questions before": would you mind rewording that paragraph in clear English please? i think understanding what you are trying to say here may be important, but you have mangled the language enough to make it ambiguous. We had many people asking in the past why they couldn't compile a development version using an older compiler of the same version (e.g. 3.3.1, though there the version check is already long in place). With the version check these questions were vastly reduced. ---------------------------------------------------------------------- robert rozee · 2026-04-27 23:45 i'm only interested in release versions. currently, i use FPC 3.2.2, and i regularly use it to recompile itself. i expect that when the next release comes out to, likewise, for it be able to recompile itself. will i be unpleasantly surprised? cheers, rob. ---------------------------------------------------------------------- MarkMLl · 2026-04-28 07:58 Quote from: PascalDragon on April 25, 2026, 05:50:01 pmQuote from: MarkMLl on April 24, 2026, 09:04:50 amI suggest that that also needs to automatically accept recompilation with the current version, not just the previous one. We don't allow that precisely to avoid people trying to compile a current 3.3.1 with an older 3.3.1 which had been regular support questions before the version check despite us saying that we only support compiling with the current official release (and the one before that). The version check can't a more granular check because the revision might have been stripped. The question arose- and I made it abundantly clear at the time- because I was trying to compile the published 3.2.2 sources with a freshly-downloaded 3.2.2 both from the FPC repository. One response- from IIRC Marco- was that in order to compile 3.2.2 I had to use 3.2.0: which didn't work because (in that particular case) changes that Debian had made to the linker etc. The other response- from you- was that in order to compile 3.2.2 I had to use 3.2.2: which quite simply didn't work because of the version check in the makefile. So while I sympathise with your requirement that a non-published development version like 3.3.1 should only be compiled by some very tightly defined prior version, I do not believe that the test you are applying to the published sources of a non-development version is reasonable. MarkMLl ---------------------------------------------------------------------- MarkMLl · 2026-04-28 08:14 Quote from: marcov on April 23, 2026, 11:35:52 amNote you can pass OVERRIDEVERSIONCHECK=1 to override for special cases, like not have a formal bootstrap version available. (as is often done for new targets). Which is neither documented (for FPC 3.2.2 or older) nor anywhere useful in the wiki. MarkMLl ---------------------------------------------------------------------- Thaddy · 2026-04-28 09:03 Because it should not be documented in the first place. Anyway, release compilers can always build themselves, it is just trunk, with its undefined status between commits. ---------------------------------------------------------------------- marcov · 2026-04-28 09:48 Quote from: MarkMLl on April 28, 2026, 10:14:22 amQuote from: marcov on April 23, 2026, 11:35:52 amNote you can pass OVERRIDEVERSIONCHECK=1 to override for special cases, like not have a formal bootstrap version available. (as is often done for new targets). Which is neither documented (for FPC 3.2.2 or older) nor anywhere useful in the wiki. Afaik the only general documentation about the build process is the buildfaq, but that is out of date. it is on my todo to revive that. Lots of useful new stuff like  FPMAKEOPT="-T 4"  and NOWPOCYCLE=1 But if you want to query about proper build procedures, please open another thread. ---------------------------------------------------------------------- robert rozee · 2026-04-28 11:13 Quote from: MarkMLl on April 28, 2026, 09:58:28 am[...] One response- from IIRC Marco- was that in order to compile 3.2.2 I had to use 3.2.0: which didn't work because (in that particular case) changes that Debian had made to the linker etc. The other response- from [PascalDragon]you- was that in order to compile 3.2.2 I had to use 3.2.2: which quite simply didn't work because of the version check in the makefile. [...] are we now dealing with Schrödinger's Cat?! i am, myself, using Linux Mint, versions 19.3 to current (22.3), with XFCE as the desktop. the version of FPC i have used for nearly 5 years is the one available in the release folders on SourceForge as linked to from https://www.freepascal.org/download.html and paired with release versions of Lazarus. The version of FPC identifies itself as "FPC version 3.2.2". i have never had any problems using this FPC 3.2.2 to recompile itself.after recompiling FPC, it has never had any problems working with the Lazarus IDE.it must be conceded that i have never had any reason to recompile for platforms other than Linux i386 and x86-64. is there any release version of FPC for Linux, as published on SourceForge, that can not recompile itself? is there any plan to make future release versions of FPC for Linux artificially incapable of recompiling themselves? note: i have not one iota of interest in the absolute mess that currently exists of GitLab; it is unstable, convoluted, experimental, and disorganized. while i applaud those brave souls who are currently attempting to create a new release version of FPC from what can at best be described as a 'dumpsite fire', i have no interest in the hoops one may have to jump through to create a build except when/if the next release of FPC is published. can anyone provide a straight answer? cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2026-04-28 11:59 Quote from: Thaddy on April 28, 2026, 11:03:19 amBecause it should not be documented in the first place. Anyway, release compilers can always build themselves, it is just trunk, with its undefined status between commits. Technically they can. But it is not supported, e.g. if you try to compile fixes, you get the error below. Formally supported is only "the last release" to compile the "next release", to build a bootstrap chain. That is already the case since before I joined last century. Which later has been extended to the last two versions in practice, as the compiler of the fixes branch is usually not that different. Code: [Select]Makefile:2835: *** The only supported starting compiler version is 3.2.2. You are trying to build with 3.2.4..  Stop. (so despite the message 3.2.0 will work too, the message only lists the formal spec) The check is deliberately simple and basic, so that catches a number of wrong combinations (deliberate or not) for simple building.  For all other special cases (like bootstrapping on an OS where the last release doesn't work) there is OVERRIDEVERSIONCHECK define. Note that this check already exists this way since 2.6.2 or 2.6.4 or so, and extended to two versions iirc around 3.2.0. ---------------------------------------------------------------------- Fred vS · 2026-05-05 14:08 Congratulations on the many commits made in the fixes_fpc_32 branch. It seems the next release will be fpc 3.2.4 RC2. Does this mean the final version 3.2.4 will have to wait a little longer? ---------------------------------------------------------------------- Thaddy · 2026-05-05 14:29 As I understand it, there is an effort to get it over with. If that is what you mean. So test it once announced and DO NOT ASK FOR ANY NEW FEATURES. Check for bugs. Anything else will delay any progress. ---------------------------------------------------------------------- JCLRQ · 2026-05-08 13:28 I do not want to stress the developers. But this is the reason, we need to accelerate on fpc release. Here are the metrics for my project. Honestly i was not expecting that much  . There is no code change between both just a rebuild: Metric                         FPC 3.2.2 (Old)   FPC 3.3.1 (Trunk)   Improvement Throughput (GEN work)   4,648 units   5,008 units            +7.7% Total Structs Produced   641                   694                          +8.3% Archive Merging Time           735 ms           349 ms                  +52.5% reduction Merging Efficiency          30.6 ms / merge   11.2 ms / merge   ~2.7x faster Built for: x86-64-Win 64, AVX2 ---------------------------------------------------------------------- robert rozee · 2026-06-27 13:50 there seems, once again, to be silence on the progress of the mythical fpc 3.2.4 RC2. have we once again reverted back to the default 'do nothing' position? cheers, rob   :-) ---------------------------------------------------------------------- cdbc · 2026-06-27 15:35 The devs doing the labour, are __not__ on this forum... You're barking up the wrong tree... Try the FPC-mailinglists... ---------------------------------------------------------------------- Paolo · 2026-06-28 05:45 Quote from: cdbc on June 27, 2026, 05:35:11 pmThe devs doing the labour, are __not__ on this forum... You're barking up the wrong tree... Try the FPC-mailinglists... Yes, but the users are here. PascalDragon started the topic, an update by him here shall be very appreciated. PS: using the current fpc my code speed is increased by 20%, that is very good. ---------------------------------------------------------------------- suve · 2026-07-04 13:25 For what it's worth, Fedora Linux has been using FPC 3.2.4-rc1 for a few months now and so far nobody reported any breakage. ---------------------------------------------------------------------- AlexTP · 2026-07-28 12:38 Pls merge fix mentioned here (I dont have URL to commit): https://forum.lazarus.freepascal.org/index.php/topic,74216.msg587438.h tml#msg587438 It was related to this problem, already fixed in Git main: Quote fcl-res: COFF resource writer emits uninitialized NumAuxSymbol, producing a malformed object file Component: Packages / fcl-res Target: all COFF targets (win32/win64/wince/arm), reproduced on x86_64-win64 Severity: minor in normal use, but causes a hard linker crash with `-Xe -XX` ---------------------------------------------------------------------- marcov · 2026-07-28 13:46 As said in that thread, I can see the fix in fixes_3_2.   I think it was in the batch of fixes  1,2 months ago, as it was marked merged, but still visible in the mergelogs app that I use during mass merges. ---------------------------------------------------------------------- BSaidus · 2026-08-26 12:19 I saw the 3.2.4-rc2 in gitlab. good news ---------------------------------------------------------------------- 440bx · 2026-08-26 14:04 Quote from: BSaidus on August 26, 2026, 02:19:48 pmI saw the 3.2.4-rc2 in gitlab. good news  That is good news.  Hopefully the formal release isn't too far away. ---------------------------------------------------------------------- dbannon · 2026-09-02 06:38 Quote from: BSaidus on August 26, 2026, 02:19:48 pmI saw the 3.2.4-rc2 in gitlab. good news  yes, I noticed rc2 appeared too. But it has a confusing sort of version number. With the tagged release_3_2_4_rc1 the compiler identifies itself as 3.2.3 when, for example, its speaking to the fpc.cfg file about where units might be.  I assume that comes from the compiler->version.pas file that contains - Code: [Select]interface     const        { version string }        version_nr = '3';        release_nr = '2';        patch_nr   = '3';        minorpatch = ''; Good. But rc2, looks quite different, its compiler->version.pas says - Code: [Select]interface     const        { version string }        version_nr = '3';        release_nr = '2';        patch_nr   = '4';        minorpatch = '-rc1'; and sure enough, it believes it is 3.2.4 when, again, speaking to fpc.cfg.  Maybe this does not matter, it did upset my scripts that I use to make cross compilers, easy fixed but one or the other appears wrong ? Davo ---------------------------------------------------------------------- Thaddy · 2026-09-02 06:55 The 3.2.4 (without RC's) branch is built from fixes, not from 3.2.4RC1/RC2, and that is the correct order,  so that is a small bug indeed. Report it ASAP so it can be fixed. ---------------------------------------------------------------------- dbannon · 2026-09-02 07:36 Thanks Thaddy. Both release candidates are tags not branches. Or are they tags along a branch ? Anyway, I assume one is correct, one is wrong. If its rc1 that is wrong, little point in adding to the noise. On the other hand, if its rc2, its probably worth while, given it has not, yet been announced. Its something of a problem when 3.2.4 is released however, both the release and rc2 expect to live under a 3.2.4 directory. Hmm... Davo ---------------------------------------------------------------------- Thaddy · 2026-09-02 09:32 @dbannon I trust you reported it? or should I? Amongst probably others, Michael is preparing a release, if I understood correctly from the commits. These tiny bits help... ---------------------------------------------------------------------- marcov · 2026-09-02 09:59 - In general, releases or RCs are branched from fixes, and after branching, the version is updated. This means that fixes stays at the old version till the release (3.2.4 final) is done, and then will change to 3.2.5 - Tags are implemented as branches in both GIT and SVN.   CVS had a separation that still persists in the naming. - 3.2.4RC2 is being built, and mostly considered done. It is not announced yet. There are still a few weeks to evaluate the RC2 after it is announced before the final, where high prio fixes can be done. ---------------------------------------------------------------------- dbannon · 2026-09-03 23:32 OK, I have logged this. Still don't feel comfortable about it, its a policy problem, not a technical one. https://gitlab.com/freepascal.org/fpc/source/-/work_items/41893 Davo