It was done because of technical limitations - the compiler didn't support dynamic packages (collections of dynamic libraries). This was again due to technical limitations from the compiler having to work in multiple OSes (i'm not 100% sure on the detail) and how they share and export symbols from dynamic libraries, something that Delphi didn't have to since it only had to work with Windows and only with their own libraries. FPC and Lazarus are also technically separate projects with their own release schedules and Lazarus has to work with multiple versions of FPC that make things a bit harder. This made introducing dynamic packages very hard... and since there wasn't much of a benefit for most uses (recompiling Lazarus is almost instant after the first compile and even that takes less than a minute even on old hardware), it wasn't something that FPC developers focused on much.

Having said that, the next version of FPC will support dynamic packages. They had to change some things in how RTTI is stored, apparently, to accommodate the OS differences (this may break some programs that use the RTTI structures directly, though the fix is trivial and 99.999% of programs wont be affected - even some of my own code that does touch RTTI directly works fine in both the latest stable version and the development version).

However chances are Lazarus will still keep using the recompile approach for some time since it'll need to work with FPC 3.0.x... and also it will take some time to update all packages to work dynamically.

Anyway, what i'm trying to say, this was done due to technical issues and compiler limitations due to what FPC and Lazarus have to support and remained an issue for a long time because in practice it didn't make much of a difference. However it will soon be solved.

" Delphi didn't have to since it only had to work with Windows and only with their own libraries"

Delphi has for some years the possibility to work on more then just Windows, and still is a breeze, regardless if I targeting Android or Windows, to just "here is the package, put the component on palette" with just 2 clicks.

I really hope Lazarus will come home, like you say, with this, since Delphi is not targeting ARM in Linux, while Lazarus does. We'll see what future holds, as I have no problem using one or the other as long as the compiled project works on its intended target. Also regarding RPI, I can just install Android on RPI4 and Delphi will have no problem targeting that

AFAIK Delphi on non-Windows is very different than Delphi on Windows, exactly because of issues (and AFAIK it even used FPC for a little for non-Windows targets, though this was eventually replaced with their own code when they started using LLVM). They were perfectly fine with having differences between platforms at the core level, however this wasn't what FPC developers or Lazarus developers wanted - in general they try to have things operate as similar to all OSes as possible and they also support way more targets than Delphi, which complicates things.

In any case i was referring to Delphi in general from the start. Delphi had support for dynamic packages since version 1, but for decades they only supported Windows. FPC on the other hand had support for multiple OSes before even version 1.0 was released.

TBH i do not remember the exact details, but IIRC it had to do with memory management, symbol resolution and RTTI support across DLLs (e.g. being able to do something like "Foo is BarClass" in DLL A, Foo is an object instantiated in DLL B with a class that is only available on that DLL B but descends from a class defined in the main program whereas BarClass is a variable holding a virtual class defined in DLL C that also descends from the same class - essentially tying to merge in RTTIs from different AOT compiled modules where none has a complete view).

And of course the fact that it was a low priority issue since there wasn't any major practical drawback (personally the only issue i had was that i couldn't share the RTL and LCL between executables that i'd otherwise package together, meaning that the produced executables would take more disk space than necessary since each executable is having their own copy of the RTL and LCL instead of using them from a shared object/DLL).

Yeah, Delphi is still trying to find its compass when dealing with cross-platform. Intentions are good, just execution lacks. Problem is currently none of them (either Delphi nor Lazarus/FPC) are a good fit overall. Each solves problems on different platforms differently while having other problems that are non-existing for the other.

I do have fun playing with them though, trying to learn each what quirks lurks around. I mean one example is above I said - Delphi can target ARM if it's Android, but can't target ARM if it's Debian. So I can run on RPI something Delphi cooked if I have Android there, but if I have Raspbian I can't. Same hardware, different OS, such a hard nut to crack :). While if it's Intel and you have Linux, guess what - Delphi owns it.

So for now I am switching between IDE's/Frameworks all depending on availability of technology and most importantly what client(s) want.

Interesting. I haven't needed to do so, but I thought I had heard that was a pretty quick recompile, on the order of < 10 seconds? I know there are some tips to speed it up.

Here's the wiki page on component authoring:

https://wiki.freepascal.org/How_To_Write_Lazarus_Component

Except when you need to, it's not working, or creepy bugs won't let you do it. Do try it on Lazarus for Raspberry Pi for example (you can do it on a virtual machine if you lack the real device). You'll see what I mean.

Are you using the official releases? If you are using Lazarus from Debian or some other repository, it will not work due to these packages not setting up permissions for the executable to be replaced.

In general IME on Linux the best approach is to install FPC (either from repositories or, better, using the official release) and then download the Lazarus source code and compile it somewhere in your home directory with 'make bigide'. This will avoid any problems with Lazarus packaging that often tends to be broken (again, IME).

I used in home instead in it's official release. Also I sudo-it when launch it, so it will have full rights. On some packages it didn't work, no matter what I did. I had to use official apt from repositories for those packages (lucky me they had that).

Hm if you installed the program from the sources it should work, though you may also need to install the development packages for Gtk, etc.

You can see the whole process in this video i took a couple of years ago:

https://www.youtube.com/watch?v=s_01Xhd2EJM

(this is making a simple puzzle game)

I'm basically doing the same procedure for many years now and i never had an issue with getting Lazarus or any of its packages to work.