Recent

Author Topic: Lazarus Release 3.6  (Read 37017 times)

TRon

  • Hero Member
  • *****
  • Posts: 3928
Re: Lazarus Release 3.6
« Reply #45 on: January 04, 2025, 01:49:56 am »
If there was a simple and automated CLI way of doing so (e.g. rustup), I'd be happy to do it although the build overhead is not something that is ideal.
Well, I do it for every release using a script. The only thing required to keep from such build is the ppc executable (to be used to build the next version release). I hang on to those so that whenever a new release emerges I am able to build my own compiler immediately at release. I use the same approach for trunk.

Handling the different c-libs is solvable by different methods that are able to deal with it as long as there isn't  definitive solution offered by the team (but in case you have your own method that you are familiar with then better stick to it, e.g. a separate build setup, cross-compile, patching etc).

See also dbannon's approach/solution.
I do not have to remember anything anymore thanks to total-recall.

c600g

  • New Member
  • *
  • Posts: 45
Re: Lazarus Release 3.6
« Reply #46 on: January 05, 2025, 07:01:21 pm »

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

Quote from: dbannon
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.

Quote from: dbannon
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.

Quote from: dbannon
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

c600g

  • New Member
  • *
  • Posts: 45
Re: Lazarus Release 3.6
« Reply #47 on: January 05, 2025, 07:03:58 pm »
Handling the different c-libs is solvable by different methods that are able to deal with it as long as there isn't  definitive solution offered by the team (but in case you have your own method that you are familiar with then better stick to it, e.g. a separate build setup, cross-compile, patching etc).

If there is an alternative method which would allow me to target different versions of glibc, I'd be interested.

Thanks much,
  Alan

TRon

  • Hero Member
  • *****
  • Posts: 3928
Re: Lazarus Release 3.6
« Reply #48 on: January 05, 2025, 07:24:42 pm »
If there is an alternative method which would allow me to target different versions of glibc, I'd be interested.
It is a bit out of scope for this release thread to get into details but in case not wanting to setup a separate machine is to treat it as cross-compiling. The fpc configuration allows to chosen different object directories that are searched in order to locate the libraries to link against. It does require you to have such a system with the alternative glibc available and copy the required shared files into a separate folder on your main build machine.

The easiest way is to target the lowest common dominator as that works for higher revisions of the library as well. There are many other alternatives such as the using musl library instead. There are some threads on this forum related to the glibc issue that discuss the different approaches (in that regards your timing indicates  to have arrived a bit late at the party  :) )
I do not have to remember anything anymore thanks to total-recall.

Fred vS

  • Hero Member
  • *****
  • Posts: 3475
    • StrumPract is the musicians best friend
Re: Lazarus Release 3.6
« Reply #49 on: January 06, 2025, 05:25:01 pm »
If there is an alternative method which would allow me to target different versions of glibc, I'd be interested.
This.
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

c600g

  • New Member
  • *
  • Posts: 45
Re: Lazarus Release 3.6
« Reply #50 on: January 06, 2025, 08:06:56 pm »
If there is an alternative method which would allow me to target different versions of glibc, I'd be interested.
This.

Bookmarked! Thanks very much.

Alan

Warfley

  • Hero Member
  • *****
  • Posts: 1863
Re: Lazarus Release 3.6
« Reply #51 on: January 07, 2025, 08:18:37 pm »
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.
I mean... Ubuntu 20.04 is nearly 5 years old and will be EOL in a few month, and Ubuntu 22.04 is nearly 3 years old. Why do you develop on a system thats already 5/3 years out of date to begin with? When you start a bigger project, you want to mostly freeze the dependencies throughout the development. If you already start with something that is 5 years out of date, and then you take a few years of development time, in the end when you release your software builds up on tech thats nearly a decade old.

You can install a more up to date version of FPC and Lazarus manually (there are prebuilt binary packages with an install script for fpc and lazarus you can just build from source easily). But even better recommendation: Don't use outdated operating systems. Ubuntu is designed to not get any updates for at least 2 years, if you stay on the LTS until it's EOL up to 5 years. In the past 2 years there have been like 4 new Lazarus releases or something. And thats not just Lazarus and FPC, for example if you are using gcc for compiling C/C++ code, you only get gcc 10 on Ubuntu, while the current live version is 14.2.

I understand why companies want this stuff in their offices. All computers on the same version, no need to update regularly and to re-train staff constantly on new versions. Thats why Ubuntu does this. It's targeted at users who do not want anything on their system to ever change or surprise them
But as a developer your relationship with your PC is different, you know what is going on there and how this thing works. There is no reason to use a system designed to be always outdated. Infact it just makes your job harder

Thaddy

  • Hero Member
  • *****
  • Posts: 16520
  • Kallstadt seems a good place to evict Trump to.
Re: Lazarus Release 3.6
« Reply #52 on: January 08, 2025, 03:39:58 am »
It is actually quite common to tie a software to a particular compiler version.
The reason is simply that a new compiler version alone does not warrant a rewrite/recompile of your software.
We also versioned the compiler/toolchain with which a particular software version was built.
That is how it should be done.
« Last Edit: January 08, 2025, 09:00:35 am by Thaddy »
But I am sure they don't want the Trumps back...

PeterBB

  • New Member
  • *
  • Posts: 45
Re: Lazarus Release 3.6
« Reply #53 on: January 08, 2025, 04:24:42 pm »

... Don't use outdated operating systems ....  it just makes your job harder ....

I agree, trying to use latest dev tools in an outdated linux system is usually a pita.
Debian 12 (Bookworm) released June '23, now has latest FPC & Lazarus in Backports.

Regards,
Peter

dbannon

  • Hero Member
  • *****
  • Posts: 3212
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Lazarus Release 3.6
« Reply #54 on: January 12, 2025, 01:45:38 am »
....
I mean... Ubuntu 20.04 is nearly 5 years old and will be EOL in a few month, and Ubuntu 22.04 is nearly 3 years old. Why do you develop on a system thats already 5/3 years out of date to begin with?
....
 But even better recommendation: Don't use outdated operating systems.
While I agree (completely) about using an up to date FPC/Lazarus, the situation wrt the OS is not so simple.  I develop on Debian Bookworm but I package (including compile) on a U20.04 VM. While I choose to use Bookworm, I have no control on what OS my end users use. And a surprising number do use old-ish if not out of date OS.

https://ubuntu.com/blog/ubuntu-20-04-lts-end-of-life-standard-support-is-coming-to-an-end-heres-how-to-prepare

The second is to obtain Expanded Security Maintenance and extend the support period for 20.04 LTS until May 2030 with an Ubuntu Pro subscription...... Ubuntu Pro is always free for personal use.

For the corporate users, a decision to pay a subscription is easy, they are used to paying for software.

There are several linux distros who clone (eg) Ubuntu and their release cycle is sometimes less predictable than Canonical's.
 
Many corporate users use RedHat, and that is subject to quite extensive long term support too. I have used RedHat on a couple of Supercomputers and found their support quite reasonable but old code frustrating.

So, yes, in an ideal world, the transition between glibc would be well behind us, but it is, now, a real thing and will be for some time to come.

Besides, building releases on a isolated and reasonably static (apart form official updates) machine has a number of quality benefits too.

Davo

 






Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

c600g

  • New Member
  • *
  • Posts: 45
Re: Lazarus Release 3.6
« Reply #55 on: January 14, 2025, 12:01:39 am »
I mean... Ubuntu 20.04 is nearly 5 years old and will be EOL in a few month, and Ubuntu 22.04 is nearly 3 years old. Why do you develop on a system thats already 5/3 years out of date to begin with? When you start a bigger project, you want to mostly freeze the dependencies throughout the development. If you already start with something that is 5 years out of date, and then you take a few years of development time, in the end when you release your software builds up on tech thats nearly a decade old.
[\quote]

I explained it in a previous message, however I will summarize it here:

1. Our company sells a product (calculation library) which has been developed over 20+ years.

2. One of our largest customers uses the library on AWS ECS instances that are running Amazon Linux 2 (AL2). AL2 is shipped with glibc 2.26, and is supported through 2026-06-30. Thus, we need to support this as well, or tell the customer to go pound sand (usually not a good idea if you want to keep doing business with said partner).

I am not using Ubuntu 20.04 as an active desktop nor development platform - I'm using it to build releases that are backwards compatible for this customer. That is all.

Alan

Warfley

  • Hero Member
  • *****
  • Posts: 1863
Re: Lazarus Release 3.6
« Reply #56 on: January 14, 2025, 01:46:08 am »
But you can develop on an up to date system and still target older systems. Afaik the FPC is not deeply linked to the libc, but it's just another library to be linked against. So you should just be able to get an older libc version (e.g. by compiling it from source) and linking against it by using the -XR option of the FPC, which prepends the library search path for the linker, making it chose this libc over the system default libc

TRon

  • Hero Member
  • *****
  • Posts: 3928
Re: Lazarus Release 3.6
« Reply #57 on: January 14, 2025, 02:09:54 am »
But you can develop on an up to date system and still target older systems. Afaik the FPC is not deeply linked to the libc, but it's just another library to be linked against. So you should just be able to get an older libc version (e.g. by compiling it from source) and linking against it by using the -XR option of the FPC, which prepends the library search path for the linker, making it chose this libc over the system default libc
For sure but then there is a fundamental question such as where do we get this libc from ? It also adds other complexity because any other library that the code links against might rely on a newer libc thus you would also would need to obtain those. The whole reason for the change with libc was that some external libraries are now included inside libc which (for the uninitiated) complicate things in a rapid manner.

If one has experience with cross-compiling then this would be almost as second nature but might perhaps not be for everyone.
I do not have to remember anything anymore thanks to total-recall.

dbannon

  • Hero Member
  • *****
  • Posts: 3212
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Lazarus Release 3.6
« Reply #58 on: January 14, 2025, 03:25:19 am »
But you can develop on an up to date system and still target older systems. Afaik the FPC is not deeply linked to the libc, but it's just another library to be linked against. So you should just be able to get an older libc version (e.g. by compiling it from source) and linking against it by using the -XR option of the FPC, which prepends the library search path for the linker, making it chose this libc over the system default libc

A group tried to do just that. And perhaps proved it possible if not particularly practical. Think it ended here -
https://forum.lazarus.freepascal.org/index.php/topic,58888.msg494938.html#msg494938

As I said, having a system using the early libc tucked away to do the final, release, build is simple, reliable and cheap (using, of course, a VM). I recommend U20.04 as a well maintained example, obviously lots of others. At some stage, I will have to consider registering for the extended support, free for non-commercial.

Davo


Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

robert rozee

  • Full Member
  • ***
  • Posts: 208
Re: Lazarus Release 3.6
« Reply #59 on: January 14, 2025, 02:59:03 pm »
But you can develop on an up to date system and still target older systems. Afaik the FPC is not deeply linked to the libc, but it's just another library to be linked against. So you should just be able to get an older libc version (e.g. by compiling it from source) and linking against it by using the -XR option of the FPC, which prepends the library search path for the linker, making it chose this libc over the system default libc

A group tried to do just that. And perhaps proved it possible if not particularly practical. Think it ended here -
https://forum.lazarus.freepascal.org/index.php/topic,58888.msg494938.html#msg494938

a working method is posted in the first message of the thread here:
https://forum.lazarus.freepascal.org/index.php/topic,64731.0.html

i've just verified that it still works with Lazarus Release 3.6 (FPC 3.2.2). attached below is a zip file containing two short include files, each containing a description of where abouts in pdecsub.pas they need to be $Included (instead of the original instructions to replacing pdecsub.pas). apart from this change, the original instructions remain the same:
  • copy rebuild.sh to /usr/share/fpcsrc/3.2.2 and flag the file as executable
  • create a symlink from libdl.so to libdl.so.2 using:
        sudo ln -s /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libdl.so
  • unzip MakeBase.zip somewhere in your user directory and build it. run it from a console - no need for sudo as it just creates a data file in /tmp that the FPC compiler uses
  • go to the fpcsrc directory where you copied rebuild.sh to and run it with:
        sudo ./rebuild.sh

i've been waiting for OVER A YEAR for someone to create a single program (or script) encompassing the above steps, that folks can just compile and run to patch then rebuild the FPC compiler. it is NOT ROCKET SCIENCE.


cheers,
rob   :-)

 

TinyPortal © 2005-2018