OK, I see what you are doing. All I can think of is a script that first installs the U20.04 repo FPC, downloads, perhaps 3.2.4rc1 and builds it (from memory 3.0.4 will build 3.2.4rc1 but maybe not ?). Then, download Lazarus 3.6 source and build that. It does sound complicated but once scripted, easy enough and probably quite reliable.
And as the new versions of Lazarus require a new libqt5pas, if I want to distribute Qt5 versions of the testing apps, things get a bit more complex. At least Gtk2 never changes! :-s
If you are using things like ssl then a newer FPC is a pretty good idea. And each release of Lazarus is usually just a bit better in lots of different ways. I most certainly insist on using the latest possible. On an official Debian build for example, that means FPC322 and Lazarus 3.6 because its Trixie and the glib issue does not exist. But for my "one size fits all" packages, I build on a U20.04 VM with the updated FPC/Lazarus manually installed.
I think that I may simply target the FPC compiler version as 3.2.2, and use the latest Lazarus builds that don't break libqt5ps requirements. So, for Ubuntu 20.04 I could install Lazarus 2.2.6 from the .deb files (which includes FPC 3.2.2). The same combination would also be used with Ubuntu 22.04, and so on with each distro/release I need to support.
Instead of building on a Github runner, I understand (actually, I don't understand) you can use a prebuilt docker image, maybe self hosted ? That way, the messy process of setting un the U20.04 machine is only done once.
I thought of this as well, but was hoping for an easier solution.
One more wild suggestion, getting dodgy here I am afraid. As I build quite a lot of VMs for testing, I got sick of the "install an old compiler and then use that to build a new one" model, slow and disk consuming. So, I keep some prebuilt FPC3.2.4rc1 "images" https://github.com/davidbannon/FPC_Laz_Install that gets me a ready to run FPC324rc1 compiler without the intermediate steps. Its personalised for me although you are welcome to use them (you should allow me to update that repo first). Or you just copy the idea. It works for me !
Thanks for all the suggestions, Dave. It is appreciated. Our main product is a shared library that provides calculation functions for financial institutions, so the newer version of glibc gets involved with dlopen, dladdr, dlclose (all GLIBC2.34 it seems), etc. We have several clients who use this product in the AWS environment on amazonlinux2 images, which only provides the older glibc. As amazonlinux2 has an EOL through mid 2026, this means we have to support that platform as well.
Our newer API server avoids these issues by running in a container that we create and distribute, and it is very nice indeed to avoid these issues. We have many legacy clients that still use the library, however.
Alan