Lazarus 2.2.6 on Raspberry Pi lazarus / 32-Linux ---------------------------------------------------------------------- pleumann · 2023-07-13 15:40 Hi, continuing my questions from https://forum.lazarus.freepascal.org/inde x.php/topic,62620.msg485236.html#msg485236 regarding the availability of Lazarus 2.2.6 for Raspberry Pi OS... I was able to download and build the source for 2.2.6 on the Pi 400 itself. Building was actually quite fast, just 5 minutes or so. Nice! Two problems/questions, though: 1) When starting, the wizard would complain about the lack of fppkg.cfg, which I'd never seen before. I couldn't find this file anywhere on my disk. There was an option to restore it, but that would complain about not knowing the FPC prefix. I tried to give it /usr/bin/fpc or /usr/share/lib/fpcsrc (from the back of my head), but it would accept neither. What do I have to do here? I was able to start the IDE anyway, and it seemed to run fine, but I'm worried I might run into trouble later. 2) The FPC in latest Raspberry Pi OS with which I've build Lazarus comes from the apt package manager. It is 3.2.0, not 3.2.2. Is that the root cause for my above problem or might that be a cause of other problems later? So far my application has been running fine when built with FPC 3.2.0 and Lazarus 2.0.10, but maybe Lazarus 2.2.6 expects FPC 3.2.2 and 3.2.0 is too old? Cheers! Joerg ---------------------------------------------------------------------- rvk · 2023-07-13 16:16 Should be fixed in trunk. https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40336 What happens if you let it create the file? Does it look like the one in the bugreport? Then there is no further problem. ---------------------------------------------------------------------- TRon · 2023-07-13 16:25 Quote from: pleumann on July 13, 2023, 05:40:17 pmWhen starting, the wizard would complain about the lack of fppkg.cfg, which I'd never seen before. it is/was a known issue with Lazarus 2.2.4/2.2.6 (fpc 3.2.2) and afaik these issues with fppkg.cfg where 'fixed' with the release of lazarus 3.0Rc1. It is not a critical issue and can be ignored (i did so with 2.2.4/2.2.6 and never ran into issues). Having said that you probably will run into issues when actually making use of the Free Pascal package manager (fppkg) with these Lazarus versions when Lazarus complains about it on startup. QuoteThe FPC in latest Raspberry Pi OS with which I've build Lazarus comes from the apt package manager. It is 3.2.0, The official supported Free Pascal version for Lazarus 2.2.6 is FPC 3.2.2. Other combinations are officially not supported. I'll let you in on a little secret. It is just as easy to build Free Pascal 3.2.2 from source (or Lazarus 3.0rc1 for that matter). You can use your 3.2.0 compiler as bootstrap compiler if you want to update your Free Pascal compiler. For instructions on how to do that yourself see: https://wiki.freepascal.org/Installing_the_Free_Pascal_Compiler ---------------------------------------------------------------------- rvk · 2023-07-13 16:55 Quote from: TRon on July 13, 2023, 06:25:01 pmI'll let you in on a little secret. It is just as easy to build Free Pascal 3.2.2 from source (or Lazarus 3.0rc1 for that matter). You can use your 3.2.0 compiler as bootstrap compiler if you want to update your Free Pascal compiler. For instructions on how to do that yourself see: https://wiki.freepascal.org/Installing_the_Free_Pascal_Compiler Ha, they got bootstrap again for multiple platforms !!!  There was a time where they just didn't create (all) them. They said the only official way would (and will always be) using a complete official release of FPC. So you would need to download and install a complete FPC installation to create a new trunk version of FPC. Quote from: Jonas Maebe on August 25, 2015, 02:33:17 pmThe only supported way to bootstrap FPC always has been and always will be based on a complete installation of the previous official release. The bootstrap compilers are sometimes uploaded for certain source-centric packagers, but they are 100% unsupported and you should not use them. If it were up to me, all of these bootstrap compilers would be removed from the ftp site, because using them instead of a full installation can lead under some circumstances to hard to diagnose problems if you don't know the details of the FPC build process. https://forum.lazarus.freepascal.org/index.php/topic,29452.0.html I can adjust my scripts again to use the bootstrap instead of downloading a complete FPC installation just to extract the compiler to use it for my trunk installs  https://downloads.freepascal.org/fpc/beta/3.2.0-rc1/bootstrap/ (Although that's still not official is my guess... I've never had problems with it.) EDIT: AAAAAAARG !!!! In the Makefile of FPC: REQUIREDVERSION=3.2.2 And there is no bootstrap for 3.2.2 https://downloads.freepascal.org/fpc/beta/3.2.2-rc1/ (There is a REQUIREDVERSION2=3.2.0 so maybe it still works... but definitely not supported) ---------------------------------------------------------------------- TRon · 2023-07-13 17:09 Quote from: rvk on July 13, 2023, 06:55:41 pmSo you would need to download and install a complete FPC installation to create a new trunk version of FPC. ha !  Just like you I got a nifty script that downloads (pipes) the tarball (from SF) and do a on the fly extraction for the ppc executable only (otherwise it would just waste diskspace). edit btw: I don't think fpcupdeluxe would be so popular if that requirement would be met Also, just like you I started out with using the available bootstrap compilers on the ftp site but I got a lot of issues with the site being unreachable at times, bootstrap compilers that I needed not being present (or compiled wrong as some targets are difficult) and the stupid renaming of filenames and directories. In the end i figured the SF site is more consistent (though also having its perks). BTW thank you make file builders and tarball creators for the everlasting changes in (confusing) naming schemes. QuoteEDIT: AAAAAAARG !!!! In the Makefile of FPC: REQUIREDVERSION=3.2.2 And there is no bootstrap for 3.2.2 https://downloads.freepascal.org/fpc/beta/3.2.2-rc1/ (There is a REQUIREDVERSION2=3.2.0 so maybe it still works... but definitely not supported) I have no problem compiling 3.2.2 with 3.2.0 so unless something changed recently ? That said, I use the release version, not release candidate (so perhaps that differs ?) ---------------------------------------------------------------------- JuhaManninen · 2023-07-13 22:31 Quote from: TRon on July 13, 2023, 06:25:01 pmThe official supported Free Pascal version for Lazarus 2.2.6 is FPC 3.2.2. Other combinations are officially not supported. Actually any Lazarus version should compile and work with 2 latest FPC release versions, now meaning FPC 3.2.0 and FPC 3.2.2. Lazarus trunk also supports FPC trunk. Thus FPC 3.2.0 from a distro server should be OK for Lazarus 2.2.6. If it does not compile, it is a bug in Lazarus 2.2.6 but it will not be fixed any more. I still recommend Lazarus fixes_3_0 branch for anybody who must build from sources. It has the same compiler requirements, FPC 3.2.0 and FPC 3.2.2. It is a major release and has all the new development from the past almost 2 years, including Martin's debugger improvements, plus all the bug fixes. It is certainly better than Lazarus 2.2.6. ---------------------------------------------------------------------- TRon · 2023-07-14 23:50 Thank you for the correction JuhaManninen as I was not aware. Is that (officially) documented somewhere (if it is then I must have overlooked) ? (so that it can be quoted/referred) fwiw: I did came across this wiki FAQ answer but that doesn't really emphasize (explicitly) on the last 2 versions. ---------------------------------------------------------------------- JuhaManninen · 2023-07-15 06:36 Quote from: TRon on July 15, 2023, 01:50:24 amThank you for the correction JuhaManninen as I was not aware. Is that (officially) documented somewhere (if it is then I must have overlooked) ? (so that it can be quoted/referred) fwiw: I did came across this wiki FAQ answer but that doesn't really emphasize (explicitly) on the last 2 versions. Good point. I don't know if it was documented. I added it to the FAQ page you linked. Lazarus 2.x requirements there could have more details. If somebody wants to dig the timeline, please update the page. It is also possible the "2 latest FPC versions" rule does not hold always. ---------------------------------------------------------------------- TRon · 2023-07-15 20:22 Quote from: JuhaManninen on July 15, 2023, 08:36:23 amGood point. I don't know if it was documented. I added it to the FAQ page you linked. Thank you very much for having done so JuhaManninen. QuoteIt is also possible the "2 latest FPC versions" rule does not hold always. Fair enough, I consider it similar as the bootstrap compiler for FPC. Officially only the previous dot release but sometimes possible with an earlier version (though not officially supported in that case). ---------------------------------------------------------------------- pleumann · 2023-07-16 07:39 Hi everyone who responded, thanks again for all the hints and pointers. I was able to build FPC 3.2.2 on an M1 Mac from itself (i.e. from the installed version). It seemed to work fine, although I wasn't sure whether it's wise to run it from the source directory or if it maybe should be installed into the canonical directories. On an Intel Mac the build failed in one of the final steps with "ld: library not found for -lc", which seems kind of weird. I do have gcc installed, in case that is supposed to be the "ordinary" libc. Maybe I'll dig a little deeper later. So far I haven't had a lot of time. Both builds were only a test, though. My Raspi 400 is at the office, so I can try building 3.2.2 using 3.2.0 on that hardware early next week. Depending on how that works out I will decide which FPC version to use for building Lazarus. But since 3.2.0 seems to be in the "supported" range, maybe I'll play safe in the end. Either way, I'll keep an eye open for Lazarus releases and as soon as 3.0 is official, I'll consider switching. But given the pretty tight timeline of my project I find 2.2 -> 3.0 too big a leap to use an RC. Cheers! Joerg ---------------------------------------------------------------------- TRon · 2023-07-16 12:42 Quote from: pleumann on July 16, 2023, 09:39:07 amI was able to build FPC 3.2.2 on an M1 Mac from itself (i.e. from the installed version). It seemed to work fine, although I wasn't sure whether it's wise to run it from the source directory or if it maybe should be installed into the canonical directories. make clean install PP="path_and_filename_to_ppcXXX_executable_from_fpc_3.2.0" INSTALL_PRE FIX="path_to_where_you_want_to_install_the_compiled_free_pascal_3.2.2" Additionally you can also decide to customize details (by adding): INSTALL_BASEDIR="path_to_basedir" INSTALL_LIBDIR="path_to_libdir" QuoteOn an Intel Mac the build failed in one of the final steps with "ld: library not found for -lc", which seems kind of weird. It is quite common that you need to manually change/add the fpc.cfg file Some example for Linux: 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 #ifdef LINUX#ifdef CPUARM-Fl/usr/lib/gcc/arm-linux- gnueabihf/6.3.0#endif#ifdef CPUX64-Fl/usr/lib/gcc/x86_64-linux- gnu/12#endif#endif I have no idea where macos stores those libraries so you would have to verify. You can always pass -va to the compiler when compiling (a small test project) to (also) output information on what goes wrong whn processing the fpc.cfg file and during compilation/linking (usually that contains some additional information such as directory/file not found and an error-code). QuoteBut since 3.2.0 seems to be in the "supported" range, maybe I'll play safe in the end. Though supported I would personally opt for 3.2.2 if only because of the fixes that where made since the release of 3.2.0. QuoteI find 2.2 -> 3.0 too big a leap to use an RC. The jump in version numbers is mainly because of the change of using a new version scheme for releasing Lazarus but I do agree that for production code it is perhaps preferred to skip the release candidate(s). ---------------------------------------------------------------------- pleumann · 2023-07-21 09:40 Following up on this one, I think I've been able to build build FPC 3.2.2 with the help of the 3.2.0 coming from Raspberry Pi OS's package manager. At least there was no error message. But: Whenever I called it, I still got 3.2.0 as version info. So maybe there is an indirection I am not aware of (and fpc itself is only the frontend to other binaries). I then tried the install option, and that went really weird. It did create all the directories needed, but there were no files inside. No error message either. I don't have access to the machine today, but will keep trying next week. I wonder if I should move this part of the thread elsewhere because it's now mostly related to FPC. So maybe "Free Pascal / Unix" or "Free Pascal / Other OS" would be a better place? I also gave building 3.0 RC1 a shot. It seemed to work fine, so I may switch as soon as there is a release. I noticed at least one improvement for my project already: It was suddenly possible to have transparent panels on Linux/GTK, something I couldn't manage with the previous version(s). Last but not least, I ran into one problem that may be a regression in 2.2.6 and 3.0 RC1, but happens only on the Pi and only under special circumstances: When starting a graphical application, even a trivial "Hello World" one, there is a grey box for quite a while before the actual window appears. This does not happen when I start an application on my development Pi 400 from the graphical environment. It does happen though, on our deployment Pi 4 (which runs a stripped- down Raspberry Pi OS and a simple window manager). An easy way to reproduce the behavior is to switch to a separate login shell and do "startx ./project1". I uploaded a YouTube video showing this: https://youtu.be/wkQIumHgcks Now, I wouldn't bring this here at all behause the circumstances are so special, but the funny thing is: It does not happen if the application is created with Lazarus 2.0.10. I wonder what is going on here. Why does the application take so long to start? Is it triggering the loading of shared libraries? Is the gray box an empty "root" window that is being created, but now yet filled with controls? And why does this happen only with the recent Lazarus versions? Cheers Joerg ---------------------------------------------------------------------- rvk · 2023-07-21 14:04 Quote from: pleumann on July 21, 2023, 11:40:28 amLast but not least, I ran into one problem that may be a regression in 2.2.6 and 3.0 RC1, but happens only on the Pi and only under special circumstances: When starting a graphical application, even a trivial "Hello World" one, there is a grey box for quite a while before the actual window appears. This does not happen when I start an application on my development Pi 400 from the graphical environment. It does happen though, on our deployment Pi 4 (which runs a stripped-down Raspberry Pi OS and a simple window manager). An easy way to reproduce the behavior is to switch to a separate login shell and do "startx ./project1".And is X already started or does it need to start from scratch (in which case a long delay would be expected)? You say this is a regression. Are you sure it started in 2.2.6 directly (on the same configuration)? ---------------------------------------------------------------------- pleumann · 2023-07-21 15:18 Quote from: rvk on July 21, 2023, 04:04:39 pmQuote from: pleumann on July 21, 2023, 11:40:28 amLast but not least, I ran into one problem that may be a regression in 2.2.6 and 3.0 RC1, but happens only on the Pi and only under special circumstances: When starting a graphical application, even a trivial "Hello World" one, there is a grey box for quite a while before the actual window appears. This does not happen when I start an application on my development Pi 400 from the graphical environment. It does happen though, on our deployment Pi 4 (which runs a stripped-down Raspberry Pi OS and a simple window manager). An easy way to reproduce the behavior is to switch to a separate login shell and do "startx ./project1".And is X already started or does it need to start from scratch (in which case a long delay would be expected)? You say this is a regression. Are you sure it started in 2.2.6 directly (on the same configuration)? I am not sure it's a regression. And the case is so special that it may be of no real interest to anyone except me. I'm mainly hoping that it might ring a bell and someone can point me into the right direction. I have three environments, all based on latest Raspberry Pi OS 32 bits: 1) Pi 400 with a full desktop that I use for development. Application launches in a second from both Lazarus and an xterm. No gray box. 2) Pi 4 with a stripped-down system that we actually deploy to. X is already started. Application takes ages to start from an xterm, shows gray rectangle during that time. 3) Said Pi 400, but with a separate (text mode, i.e. Ctrl-Alt-Fx) login shell where I do "startx ./project1" to launch X and the application in a single go. This gives me the same behavior we see in 2), so it could be used as an easy mans of reproducing (if someone wanted to). I cannot post any of our real code, but it happens with any basic single-form application, too (see video). So you just need to create a new project, then build. Now, I would have blamed it on our special environments and the necessity of maybe loading some X libraries while launching the application, but: a) It is taking very long even for that. b) It is showing this empty gray window. c) It does not happen if the application is compiled with Lazarus 2.0.10 (which is standard on Raspberry Pi OS). We've also not seen it on other architectures / operating systems so far, just Pi OS. Please note I needed to use FPC 3.2.0 to compile both Lazarus 2.2.6 / 3.0 RC1 and the application (see earlier posts in this thread), so it could also be the combination of the older FPC and the newer Lazarus. Cheers Joerg ---------------------------------------------------------------------- TRon · 2023-07-22 12:14 Initially I did not wanted to defer from the current issue being discussed but since it might perhaps be related (longshot). When I start Lazarus (3rc1) for the first time or installed anchordsgn package (made it active) and then lazarus will not show it's face directly. Initially it shows me an empty window and shows a lot of flickering action (no widgets visible though, only window borders with grey content). Only after I try to move the window (activation alone is not enough) the loop it is stuck in seems broken and the window will show it's contents (in case of anchordockdsgn) or start opening all the other windows (in case of Lazarus withouth anchordockdsgn installed/active). For me it is fairly easy to reproduce but also not a real issue but if that behaviour has by any chance the same origin and as such is also reproduced in created projects then that might perhaps act/behave in a different way. Note that my compiled projects do not seem to suffer from this issue (but also that it might perhaps requires a particular trigger to initiate). I do not require any assistance for my own issue though if someone thinks it might be helpful for TS' case then feel free to guide me with producing a log that might be of help. gtk2 Linux (bookworm) x86_64, fpc 3.2.2 lazarus 3.0rc1 (I still need to build and test with fixes) but also 2.2.6 showed similar behaviour. ---------------------------------------------------------------------- pleumann · 2023-07-27 09:30 Continuing this, we noticed two things: 1) The time we see the grey box is pretty close to 10s, which does smell like a timeout of some kind. 2) The order in which shared libraries are listed in the binaries differs when building with Lazarus 2.0.10 vs. 2.2.6 and 3.0 RC1. See screenshot. We wonder if that might be the reason (especially loading GTK before X11). Is this order hard-coded somewhere or does this stem from the order in which units are used? If so, how could we try to enforce the original order to see if that helps (because I assume this is happening deep down in the unit tree of the RTL/FCL/LCL)? Cheers Joerg ---------------------------------------------------------------------- pleumann · 2023-07-27 13:40 And yet more findings: - It's not the order of shared libraries. We've been able to force a different one and it didn't change things. - It's not a timeout. The delay depends on the CPU speed of the machine (Pi 400 is slightly faster that Pi 4). - It also happens on an Intel machine with Ubuntu. It's just barely noticeable because the CPU is so fast. - Again when building with Lazarus 2.0.10 on Ubuntu, the application launches instantly, no grey box. We've been able to narrow it down to TApplication.CreateForm. This is where the delay happens. So there must have been a change in the application's startup behavior on Linux/GTK in general (not just Raspberry Pi) between 2.0.10 and 2.2.6 that triggers our problem. While I admit that our circumstances are a bit special (no or non- standard window manager) I hope that this information rings a bell. ---------------------------------------------------------------------- pleumann · 2023-07-27 15:34 Ok, after several hours of adding debugging statements to the LCL (discovering DebugLn and other niceties in the meantime) I found the culprit in Gtk2WSForms. The attached screenshot shows the change between 2.0.10 and 2.2.6 that triggered it. This call adds the gray box and the 10 second delay on my Raspberry Pi (given the special circumstances I described). If I add the command line parameter mentioned in the code everything becomes instant again, as it was with 2.0.10. While I can live with that as a workaround, maybe someone can explain to me what this is actually supposed to be good for. That was quite the rabbit hole... but in a fun way. Cheers Joerg ---------------------------------------------------------------------- JuhaManninen · 2023-07-28 09:36 Quote from: pleumann on July 27, 2023, 05:34:18 pmIf I add the command line parameter mentioned in the code everything becomes instant again, as it was with 2.0.10. What is that command line parameter? QuoteWhile I can live with that as a workaround, maybe someone can explain to me what this is actually supposed to be good for. What does the commit message say? Commit's HashID? Author? Date? ---------------------------------------------------------------------- pleumann · 2023-07-28 10:08 Quote from: JuhaManninen on July 28, 2023, 11:36:39 amQuote from: pleumann on July 27, 2023, 05:34:18 pmIf I add the command line parameter mentioned in the code everything becomes instant again, as it was with 2.0.10. What is that command line parameter? QuoteWhile I can live with that as a workaround, maybe someone can explain to me what this is actually supposed to be good for. What does the commit message say? Commit's HashID? Author? Date? The parameter (for the actual application, not Lazarus) is --disableaccurateframe. In the meantime I did find it in the 2.2 release notes. It is supposed to make window frames "more accurate" under X11. Apparently it has side effects for special circumstances/environments. Did no go chasing for a git commit yet. Cheers Joerg ---------------------------------------------------------------------- pleumann · 2023-07-28 10:19 Update... this one: commit f2f8feab9b0388268fa736e9c8bb8af69a93242f Author: zeljko Date:   Thu Apr 16 09:24:25 2020 +0000     Gtk2: implemented accurate frame under x11. fixes issue #36897     Gtk2: fixed Screen.WorkAreaRect. issue #36919 https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/36897 Should I contact the author or add a comment to the original ticket or is my case too special? ---------------------------------------------------------------------- JuhaManninen · 2023-07-28 10:52 Quote from: pleumann on July 28, 2023, 12:19:20 pmcommit f2f8feab9b0388268fa736e9c8bb8af69a93242f Author: zeljko Date:   Thu Apr 16 09:24:25 2020 +0000     Gtk2: implemented accurate frame under x11. fixes issue #36897     Gtk2: fixed Screen.WorkAreaRect. issue #36919 https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/36897 Should I contact the author or add a comment to the original ticket or is my case too special? OK. Issue #36897 seems to be locked. You cannot add comments there. Even I cannot reopen it. You should open a new ticket. Add a link to this forum thread and explain the problem. We can add issue #36897 as related to it. If it cannot be fixed for your special case, the --disableaccurateframe sounds like a good workaround. Every user of your application must then have knowledge of that parameter. ---------------------------------------------------------------------- pleumann · 2023-07-28 13:19 Quote from: JuhaManninen on July 28, 2023, 12:52:56 pmQuotehttps://git lab.com/freepascal.org/lazarus/lazarus/-/issues/36897 Should I contact the author or add a comment to the original ticket or is my case too special? OK. Issue #36897 seems to be locked. You cannot add comments there. Even I cannot reopen it. You should open a new ticket. Add a link to this forum thread and explain the problem. We can add issue #36897 as related to it. If it cannot be fixed for your special case, the --disableaccurateframe sounds like a good workaround. Every user of your application must then have knowledge of that parameter. I'm fine with the workaround. Our application is running in kiosk mode on a custom Raspberry Pi system. I will still create a ticket later. Maybe the solution for #36897 can be modified to work with non- standard desktop environments, too. Cheers! Joerg