Lazarus Bugfix Release 3.8

[robert rozee]

The Debian package of Lazarus is still not usable on Debian 11:

Code: [Select]

startlazarus: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by startlazarus)Can we request a package for Debian 11?

have noticed that too - it has not been built on an 'old distro'. the 32-bit version does not suffer from this problem.

when will it be time to incorporate my patches for pd_external() that enables compiling an ELF binary on ANY age of x86 system, that can be then subsequently run on x86 systems with ANY version of GLIBC installed?

for the required code see the attachment to my posting here:
https://forum.lazarus.freepascal.org/index.php/topic,68708.msg543537.html#msg543537

this will then enable building distributions of FPC and Lazarus that will run on OLD and NEW Linuxes.


cheers,
rob   :-)

[robert rozee]

The Debian package of Lazarus is still not usable on Debian 11:

Code: [Select]

startlazarus: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by startlazarus)Can we request a package for Debian 11?

the solution may be stupidly simple. open a terminal window and type in:

user@Mint19:~$ cd /usr/share/lazarus/3.8.0
user@Mint19:/usr/share/lazarus/3.8.0$ sudo make bigide

much text will scroll up the terminal window, and after a minute or so the Lazarus IDE will have been rebuilt and be able to run. i just did this in a Linux Mint 19.3 VM and the process took less than a minute.

one has to ask the question: would it not be better to ship just only the source code for the IDE (ie, don't bother shipping a compiled binary as well) and then have the installer compile it at install-time?


cheers,
rob   :-)

addendum: in red above, clarifying that what is currently shipped is BOTH source code AND compiled binary; it seems the compiled binary is superfluous as it can be be built from the source code at install-time, and this avoids the problem of versioned symbols potentially stopping the Lazarus IDE from running.

addendum 14-march-2025: in order to build an IDE with working offline help system, use sudo make bigide. without bigide the result is a minimal IDE without the local help system. have edited the instructions above to reflect this.

[TCH]

Thanks Rob, it worked perfectly! This is much faster than if one would have to compile the entire project.

[TRon]

one has to ask the question: would it not be better to ship just the source code for the IDE and then have the installer compile it at install-time?

Thanks Rob, it worked perfectly! This is much faster than if one would have to compile the entire project.

Is it just me or... I am confused by both statements.

Lazarus comes shipped with its source-code, otherwise you would not be able to rebuild the IDE after installing a component. A full fledged Lazarus installation
should also come with FPC source-code in order for code-tools and the debugger to work correctly.

The make is simply rebuilding the IDE which is more or less the same as "compile the entire project" depending on what the original author meant by that.

[TCH]

When i compile Lazarus from source, it takes more time. Perhaps compiling like this does not compile everything.

Also, if i compile it from source, then it will not be a part of a DEB package and i cannot just uninstall it, but delete it's directories by hand, which means a manual upgrade will leave them there. This way the package is present and upgrading it will do the deleting job too, i only have to recompile some executables in the new version's directory.

[robert rozee]

Is it just me or... I am confused by both statements

my bad - i was not clear enough, have updated my earlier posting.

the problem TCH was having was that the pre-built binary shipped a part of the Lazarus 3.8.0 package would not run due to symbol versioning in said binary. that this was the problem was non-obvious to the average user. the solution was to rebuild a new binary - but how to do this is both non-obvious to the average user and not explained anywhere.

it appears that there is in fact no real need for any pre-built binary of Lazarus to even be shipped (at least wrt Lunux systems) as it can just be built at install-time from the source code using FPC; the only thing that needs to be pre-built is FPC, and instructions online say that FPC has to be installed before Lazarus, so should be available when Lazarus is being installed.


cheers,
rob   :-)

[JuhaManninen]

one has to ask the question: would it not be better to ship only the source code for the IDE and then have the installer compile it at install-time?

Yes that is one good idea. On the other hand building Lazarus from sources is very easy once FPC is installed. Get sources from Gitlab and run "make".
This has added benefits in Unix type systems. You can build under your home directory and run the binaries in-place. When installing components, building goes to the same place and not to a local config dir.
You can easily switch between development and release versions :

Code: [Select]

$ git switch fixes_4
$ git pull
$ make
$ cp lazarus lazarus_4
$ git switch main
$ git pull
$ make
$ ./lazarus

Or something similar. Then you have binaries for the development version (./lazarus) and for 4.0 (./lazarus_4) including the latest bug fixes.

For FPC project it would be beneficial to ship only the source for most platforms. IMO it would suffice to provide binaries for Windows and maybe the current MacOS (ARM).
Linux and BSD distros build their own packages anyway. It would be enough that FPC makes a release announcement and tells where the sources are.
Users of embedded and other exotic systems are used to build FPC from sources anyway, and maybe to build a cross-compiler. They don't need binaries from FPC project.
One excuse for a slow FPC release cycle has been the complicated build process for many platforms. Well, that is not needed really.
Now a fourth year since the last FPC release is counting. Will there be a 4 year anniversary? Who knows.
The current situation is unbearable. People must build FPC from fixes branch sources but distros don't use it because it is not released officially. 

[TRon]

When i compile Lazarus from source, it takes more time. Perhaps compiling like this does not compile everything.

It will only recompile the IDE and the components it depends on. Note that first time compilation requires for a widgetset to be compiled which takes longer..

Also, if i compile it from source, then it will not be a part of a DEB package and i cannot just uninstall it, but delete it's directories by hand, which means a manual upgrade will leave them there. This way the package is present and upgrading it will do the deleting job too, i only have to recompile some executables in the new version's directory.

I do not understand why one would depend on DEB or any packaging dependency when those packages are not capable of  handling multiple installations and not capable of installing things to a location where there are enough access rights (if you haven't crossed that bridge yet, then please consider yourself advised).

There is no way I will ever let any package manager make decisions for me concerning my development environment as that is an accident waiting to happen 

[TRon]

the problem TCH was having was that the pre-built binary shipped a part of the Lazarus 3.8.0 package would not run due to symbol versioning in said binary. that this was the problem was non-obvious to the average user. the solution was to rebuild a new binary - but how to do this is both non-obvious to the average user and not explained anywhere.

My bad as well, I could have guessed that. Fair enough.

it appears that there is in fact no real need for any pre-built binary of Lazarus to even be shipped (at least wrt Lunux systems) as it can just be built at install-time from the source code using FPC; the only thing that needs to be pre-built is FPC, and instructions online say that FPC has to be installed before Lazarus, so should be available when Lazarus is being installed.

It is indeed easy enough to build your own Lazarus, I have no idea why people think it is complicated. Download/clone sources, optionally extract , cd directory and build with an optional install. Done. Yes, you need to be aware that you have the dependencies in place.

Note that there is also no need for prebuild FPC. The only thing required is a FPC bootstrap compiler (the ppc executable of the previous released versions for your platform). It also requires some dependencies and a bit more knowledge on the build-system.

I use an automated personalized script to build everything from source which allows to build/test all sort of normal but also exotic combinations 

[robert rozee]

Download/clone sources, optionally extract , cd directory and build with an optional install. Done. Yes, you need to be aware that you have the dependencies in place. Note that there is also no need for prebuild FPC. The only thing required is a FPC bootstrap compiler (the ppc executable of the previous released versions for your platform). It also requires some dependencies and a bit more knowledge on the build-system.

I use an automated personalized script to build everything from source which allows to build/test all sort of normal but also exotic combinations 

well... therein lies the problem. for the 'average' user much of the above is just a tad daunting. anything more than clicking a button on a webpage to download the .deb file and then clicking on the icon of said .deb file to launch the installer is going to weed out quite a few customers.  even more daunting is the need to do this THREE times (for Linux), and in the right order. i'm afraid this is just the sad nature of the world we live in - it is necessary to cater for the lowest common denominator. sure, many of the 'two click wonders' (well, 2 clicks x3) will be totally incapable of writing the simplest pascal program, but we need to do everything we can to at least get them to the starting line.

personally, i only use the .deb packages from SourceForge, simply because i need a 100% standard installation that i can be sure works exactly the same as every other installation out there. no release candidates, no extra components installed, no additional libraries. this allows the code i create to be used by those 'two click wonders' with the maximum possible chance of them not being able to f*** it up.


cheers,
rob   :-)

[TRon]

well... therein lies the problem. for the 'average' user much of the above is just a tad daunting. anything more than clicking a button on a webpage to download the .deb file and then clicking on the icon of said .deb file to launch the installer is going to weed out quite a few customers.  even more daunting is the need to do this THREE times (for Linux), and in the right order. i'm afraid this is just the sad nature of the world we live in - it is necessary to cater for the lowest common denominator. sure, many of the 'two click wonders' (well, 2 clicks x3) will be totally incapable of writing the simplest pascal program, but we need to do everything we can to at least get them to the starting line.

That is where FPCUpDeluxe is able to chime in.

Requires only 3 or 4 clicks (some additional clicks for downloading, changing the attributes and firing it up) but then one could perhaps argue that it is too difficult to choose which should be the first click, then able to make a selection of the one or two following clicks to eventually press the correct fourth one. More clicks required if wanting to fiddle around.

In general I agree but I can't get it out of my mouth to advise a snap-pack or image or whatever the today's buzz "everything contained in a single executable' word is.

personally, i only use the .deb packages from SourceForge, simply because i need a 100% standard installation that i can be sure works exactly the same as every other installation out there. no release candidates, no extra components installed, no additional libraries. this allows the code i create to be used by those 'two click wonders' with the maximum possible chance of them not being able to f*** it up.

Fair enough, I do that at least for release testing as well. I personally never do a release test on/at my own dev machine. but instead on a VM (actually multiple different setups). For the same reasons

[TRon]

Didn't Debian 11 support in end in August of 2024? I don't know.... I don't use Debian.

Yes, but there is such a thing as LTS and ELTS. Not that I advocate to do so but it is an option.

[robert rozee]

Didn't Debian 11 support in end in August of 2024? I don't know.... I don't use Debian.

Yes, but there is such a thing as LTS and ELTS. Not that I advocate to do so but it is an option.

not to forget the: "I bought this [machine] 20 years ago, and it has performed its job just fine ever since. And now you are telling me it is 'out of support' and just because of that I need to scrap it and buy a whole new one?!". this class of question applies to all sorts of [machines] ranging from computers and their OS, to tractors and other pieces of farm machinery, along with millions of other [machines] inbetween.

i'm writing this post on an ancient netbook, running a well-out-of-service version of Linux, running last week's release of Firefox. concepts like 'out of support' are a very modern world invention that, in many cases, are driven by not-so-pure motivations.


cheers,
rob   :-)

[dsiders]

Didn't Debian 11 support in end in August of 2024? I don't know.... I don't use Debian.

Yes, but there is such a thing as LTS and ELTS. Not that I advocate to do so but it is an option.

not to forget the: "I bought this [machine] 20 years ago, and it has performed its job just fine ever since. And now you are telling me it is 'out of support' and just because of that I need to scrap it and buy a whole new one?!". this class of question applies to all sorts of [machines] ranging from computers and their OS, to tractors and other pieces of farm machinery, along with millions of other [machines] inbetween.

i'm writing this post on an ancient netbook, running a well-out-of-service version of Linux, running last week's release of Firefox. concepts like 'out of support' are a very modern world invention that, in many cases, are driven by not-so-pure motivations.


cheers,
rob   :-)

Well, no one suggested that you scrap your hardware. If the age of your OS is your badge of honor... have at it.

[dbannon]

Didn't Debian 11 support in end in August of 2024? I don't know.... I don't use Debian.

No, at any one time, Debian supports two releases, 'stable' (currently 12, bookworm) and 'old stable' (currently 11, bullseye).  And, yes, Bullseye uses the old, incompatible symbol versioning. And there are lots of other supported linux distributions around that also have that problem. Anyone making binary releases for linux MUST use an old system to do their final build, Ubuntu 20.04 or Bullseye being good candidates.

As a matter of interest, Ubuntu 20.04 will be supported under "Expanded Security Maintenance" until 2030 and and "Legacy Support" until 2032. (No, I don't know or care what those terms mean.).

Davo