Cannot execute Lazarus IDE on Linux Mint 20.1

[maurobio]

Dear ALL,

Hi, as promised here I am to report on the latest results of attempts to run Lazarus 3.8 on 64-bit Mint Linux 20.1/20.3

I can confirm that applying the simply procedure suggested by @Robert Rozee works fine! By following his enlightened advice, I gave been able to successfully run the 64-bit version of Lazarus 3.8 IDE on Linux Mint 20.1 and 20.3 after installing from the Debian packages.

I also confirm that the the 32-bit version of Lazarus 3.8 IDE can be successfully installed and executed on a 32-bit Linux Mint 19.1 without the need to recompile the IDE, which suggests that the problem is related to the 64-bit version of the IDE only.

Several useful lessons can be taken from this exchange (including to myself, who should have checked the forum first).

Thank you very much!

With warmest regards,

[dbannon]

 maurobio, great you have it working system and great you reported back !

But as a real nit picker, I have to point out just what you have done.

First, you installed the official debs, that put a whole lot of lazarus files in the (to you) read only space under /usr.  Then, because those files would not run on your older system, you overwrote the deb provided files with, generally, new versions, as root.

And it all worked, good.

But if you now use apt to remove that lazarus.deb package, apt will probably see the files have changed and refuse to remove them cleanly. Its not a great idea to fiddle with apt's view of the world.

You would, IMHO, have been far, far better off downloading the lazarus source, compiling it in your own file area and using it from there. Simple to remove, update, add additional versions and no root access required.

The underlying problem, unfortunately, is that whoever builds those deb packages is not addressing the libc issue. I use a U20.04 VM to build release of my app, having a clean system used only for release also helps pick up surprising dependency issues too.

Davo 

[TRon]

I can confirm that applying the simply procedure suggested by @Robert Rozee works fine! By following his enlightened advice, I gave been able to successfully run the 64-bit version of Lazarus 3.8 IDE on Linux Mint 20.1 and 20.3 after installing from the Debian packages.

As enlightenment that might have been and without discrediting Robert's advise it is the wrong solution. Any time you need to rebuild the IDE because f.e. of an newly installed component the IDE might refuse to do so because of the issues related to checksum errors. That is unless you run the user environment as root as well (hopefully it is clear why that should not be done).

dbannon named it nitpicking in his message, I am more firm and call it stubborn. Just install in user-space to get rid of all these issues instead of meddling along.

[robert rozee]

i've see mention of a "might" as well as a concerned "probably", yet in my experience i've never encountered any of the mentioned problems while hacking away at the Lazarus and FPC internals.

now, i must admit that i have never installed any additional components to the IDE, simply because (a) it doesn't work, and (b) the existing collection of components is rich enough to perform everything i have ever needed. to clarify upon the 'doesn't work' part, the .deb installs (under Linux) install Lazarus and FPC in such a way that adding a component to the IDE 100% fails; the IDE lacks the necessary internal mechanisms (temporarily elevated privileges) to handle rebuilding itself in the default install location.


can someone please confirm that using sudo make bigide actually (1) inhibits using apt to remove the installation, or, (2) creates a checksum error failure?

the issue of (3) installing components to the IDE, is not something that can commented on as this is not currently supported with a .deb install.


at the moment i'm not able to do any testing here, but will try to this evening.


cheers,
rob   :-)

[TRon]

i've see mention of a "might" as well as a concerned "probably", yet in my experience i've never encountered any of the mentioned problems while hacking away at the Lazarus and FPC internals.

now, i must admit that i have never installed any additional components to the IDE, simply because (a) it doesn't work, and (b) the existing collection of components is rich enough to perform everything i have ever needed. to clarify upon the 'doesn't work' part, the .deb installs (under Linux) install Lazarus and FPC in such a way that adding a component to the IDE 100% fails; the IDE lacks the necessary internal mechanisms (temporarily elevated privileges) to handle rebuilding itself in the default install location.

I am highly confused by that paragraph for several reasons.

It is normal for end-users to install components into the IDE using the accompanied (but not yet installed components), using OPM (Online Package Manager) to install 3th party components (to keep it simple those come from the interwebs) and lastly doing a manual package installation.

When the IDE is installed in a 'protected' directory it obviously will fail to (re)build at that same location. Therefor the IDE has a mechanism in place that uses the Lazarus configuration directory to 'install' the rebuild IDE. To my understanding the startlazarus command will notice this and run the correct Lazarus version for the user.

In that mechanism of building and putting things in the right location, some things currently go wrong (they are known bugs, some already fixed some are planned to be fixed), and on top of that sometime thing go wrong with the checksum checking which then triggers the need for a rebuild of a unit (which then is able to run into the same fore mentioned issue)

can someone please confirm that using sudo make bigide actually (1) inhibits using apt to remove the installation, or, (2) creates a checksum error failure?

Would love to but there is no way in h*ll I am going to do so on my development system. It took me too much sweat and tears to get things as they are (and is rock solid for a decade (might be more) now).

So, I would have to wait for my big-rig to be alive again so that I can properly test that in a vm though I have no reason to doubt it will behave as mentioned.

the issue of (3) installing components to the IDE, is not something that can commented on as this is not currently supported with a .deb install.

given my previous remarks ^^ that ^^ confuses me. Installing components has absolutely nothing to do with .deb packages. Quite honestly even if it did then I wouldn't touch those .deb packages in a million years as they will mess up an existing setup as it is impossible to do that right. Note that .debs aren't even capable of correctly supporting multiple installations.

Thus in the end that gives us a couple of approaches and the ones that include running as admin, owning the directory (though installing in user-space could be considered as such) and keep on using the .deb files or some other custom form of installation which are all not the solution to the issue. SImplest and as mentioned before: FPCUpDeluxe, or build from source. For both ways: install in user space.

edit: typo's

[dbannon]

Look folks, lets be clear here. No one is having a go at someone else, we all have techniques we use, sometimes 'informal' ones, and some of them might come at a cost. So, some observations

• I suspect most users, including ones who install from a deb (or rpm, pacman) also install packages. And it works for almost all of them. If it does not work, the reason needs to be established and, probably, fixed.
• In this case, maurobio problem was not caused by package install, it was in fact, just another case of the dreaded libc problem. He is using a quite old (but still supported ?) version of Mint. Its a well know fact that binaries made in recent versions of linux will not run in old versions of linux.
• Rob's advice of rebuilding the binaries worked because it replaced the binaries with ones build on his, older system. It had to be done as root because the apt installs into root space.
• Lazarus, because it expects to sometimes be installed in read only space, has a pretty cool but I assume quite complicated process of doing its rebuilding in user space and hiding that from the user, fortunately, only if its running from user space. Same thing if you, eg, add some debug lines to an LCL unit ?? 

That we all agree on ? My speculation -

• If Rob is unable to rebuild Lazarus, then that complicated process of using eg ~/.lazarus to store all the new files is somehow perturbed. My guess is who ever designed that process did not expect to contend with a rebuild. But that is pure speculation. But it does not worry him, great, lets leave it like that.
• If Rob or maurobio do need to rebuild lazarus before using, then, perhaps, doing that rebuild from a clean, freshly downloaded source in user space will be no harder and quite possibly deliver a better produce. Better in that (a) its not using the redirect rebuilt files process (complicated, possibly slower and fragile). (b) more flexible, you can have as many different lazarus installs as you like. (c) you are not messing with the apt database. (d) its easy to understand exactly where the lazarus and LCL fies you are using are, important if you are poking around in there, debugging or what ever. (e) its easy to blow any one lazarus install without affecting anything else.

Just my thoughts. Simpler is almost always better.

Davo

[dbannon]

Here you go Rob, on a VM, I installed fpc, fpc-src and lazarus 3.8.0. Then rebuilt lazarus in the readonly space, started lazarus up as me, installed a package (which worked fine incidently) and exited. Removed Lazarus (sudo apt remove lazarus-project).

Important, this was done on a U2404VM, so no problems with the libc issue. But, as noted, thats a known issue, expected on a Linux Mint as old as discussed (or, eg U2004, still a supported distro).

Observed, on the run where lazarus was rebuilt as root, the remove process was incomplete, not as bad as I expected but incomplete. On the run without a root rebuild, there was nothing left in root space.

Code: Bash  [Select][+][-]

1. dbannon@u2404m:~/Downloads$ sudo -i
2. root@u2404m:~# cd /usr/share/lazarus/3.8.0
3. root@u2404m:/usr/share/lazarus/3.8.0# make bigide > /tmp/lazarus.log
4. root@u2404m:/usr/share/lazarus/3.8.0#
5. root@u2404m:/usr/share/lazarus/3.8.0#
6. logout
7.  
8. # here, started lazarus in another terminal, successfully installed a package
9. # kcontrols and exited.
10.  
11. dbannon@u2404m:~/Downloads$ du -hs ../.lazarus/
12. 307M    ../.lazarus/
13. dbannon@u2404m:~/Downloads$ sudo apt remove lazarus-project
14. ...
15. dbannon@u2404m:~/Downloads$ du -hs /usr/share/lazarus/
16. 6.0M    /usr/share/lazarus/
17.  
18. # OK, same but without the sudo make bigide step
19. # removed, as root, the residual files left in /usr/share/lazarus/3.8.0
20. # installed the lazarus deb package
21. # Opened Lazarus, installed kcontrols, exited.
22.  
23. dbannon@u2404m:~/Downloads$ sudo apt remove lazarus-project
24. ...
25. dbannon@u2404m:~/Downloads$
26. dbannon@u2404m:~/Downloads$
27. dbannon@u2404m:~/Downloads$ du -hs /usr/share/lazarus/
28. du: cannot access '/usr/share/lazarus/': No such file or directory

In summary, its most certainly not a disaster, but its also not good. Maybe related, history certainly tells us an incomplete removal of Lazarus can disrupt further installs. I suspect thats not as big of a problem now as it was once. But still a worry, best avoided.

And, note I had no problems installing a package in either run. The problem you have with packages must have a deeper cause. As long as you don't need any packages, who cares ?  If you do need a package, take my advice, download a source zip, build it in user space, I bet its works as expected. Certainly no harder than what you do now.

Davo

[robert rozee]

well, i may need to eat some humble pie   

it has been a few years since i last even tried to add a component/etc to the IDE (and failed). but today i just revisited it... and succeeded! thinking back, it could well have been that back then i was running a much earlier version of Lazarus (addendum: 2.2.4?), and in particular that i had deleted startlazarus from the /usr/bin directory and replaced it with a symlink to /usr/bin/lazarus-ide. this was something recommended on the forum to get around a bug (in startlazarus) that occasionally caused the wrong .lpi file to be used from the previously opened project instead of the current project. just had a quick search through the forum, but couldn't find the original reference to this.

have used Tools -> Build Lazarus with... and it does now indeed create a .lazarus directory in the current user's home directory into which is placed all the 'expected stuff'. personally, i'm still perfectly happy with the existing locations as i don't need to add components to the IDE or add packages - i write everything i need myself.

however, i do see that Run -> Clean up and Build... does not work - although this issue is unrelated to the original poster's problem.


cheers,
rob   :-)

[dbannon]

Yep, that would do it. Startlazarus is key to that slight of hand magic. I personally don't use it, I go straight to 'lazarus' because I always build my lazarus from source and I really wonder just what that startlazarus does ...

The clean up and build  is actually important, I always use that, for example when building with a different version compiler. And, sometimes unexplainable errors go away after a "cleanup and build".  And yep, I can confirm your report, its fails on freetype.

I'll have a dig when I get time and, perhaps a bug report is in order.

Sigh ...

Davo