I am pleased to announce the first release of full dynamic package support for the Free Pascal Compiler and the Lazarus IDE. This feature has been a long time coming for the ecosystem, but a complete implementation is now available at both gitlab and as scripted downloads from my website getlazarus.org.

https://gitlab.com/sysrpl/fpc
https://gitlab.com/sysrpl/laz

An overview, demonstration, and more details are available on this page:

https://www.getlazarus.org/dynamic/

Dynamic packages allow users to create and install components, controls, and Lazarus extensions in seconds without rebuilding the entire IDE. They can also be used in your own programs to develop and deploy plugins that expose native Pascal classes and types through dynamic package libraries. To support this functionality, I have made numerous improvements to the compiler, its runtime, and the Lazarus IDE. I have also created additional IDE extensions to improve the experience of working with Lazarus packages.

Dynamic packages are implemented as standard shared library files for Linux, Windows, and macOS. They contain additional metadata generated by the compiler that can be inspected and queried using new RTL units. The runtime also includes mechanisms for safely preserving thread variables and managing dynamic types, such as strings and dynamic arrays, between programs and packages or between multiple packages.

Please let me know if you have any comments or questions.

Were you planning to create a MR on the FPC repo for the necessary changes ?

Michael.

Wow, that's a fantastic feature! Thank you very much for that.

Is it possible, to turn every `*.lpk` package into a dynamic package?

Op 18-10-2026 om 18:56 schreef Anthony Walter via fpc-pascal:

Please let me know if you have any comments or questions.

Does it tick all the boxes of packages in Delphi (reminder: https://wiki.freepascal.org/packages)

My release of dynamic packages do check off most of the items, but versioning is not done inside the package itself, but through its location on your system. For safety reasons, much like lazarus.old, when you do a build of a package it is given a specific folder with information about its successful creation time. An older copy of all packages are kept in the event you need to rollback changes due to something catastrophic. When the IDE started it will check if any of the package sources are newer than the metadata stored about the package, and a new lazprogress user interface prgoram will tell you about the changes that were detected as the IDE attempts to resolve the differences.

Similarly, users can still elect to rebuild the entire IDE, but the time will be reduced, as this process now looks it the packages it is comprised of need any rebuilding. If nothing has changed, the IDE will not be rebuilt. User can force certain items to be rebuilt by deleting the package binary.

Additionally the RTL, FLC, LCL, and most else are now in their own dynamic packages. THe RTL contains a new unit for inspecting packages using several eneuermating functions and some new types that give you RTTI about a package, and from there you can use the normal RTTI unit to gather information about what to do with the contents of a package. See the new DynPkgTypes.pas unit in the RTL for details.

Regarding the merge request, I think this needs to cook for a little while before one is sent over to the main branch,

And finally, I am limited in hardware. I do not have an M1 macintosh to test or create a branch for that CPU architecture. As such, the MacOS build I sent out is for darwin-x86_64 which will run on M1 macs, but who knows for how long. If anyone has a M1 mac that they don't want or care to donate one, I'd be happy to look at adding native M1 support for this feature.

Let me know if you have any other questions. I have been working on this feature and of my merger of tiny.sim into my unified library vigorously for quite some time, but I will be back at porting some of my old Delphi code to Lazarus this week and answering questions or fixing issues posted to those gitlab pages until we get to a point where a MR is appropriate.

Thank you all,
Anthony

Anthony Walter wrote

Please let me know if you have any comments or questions.

First some general remarks (especially if you want to work towards creating a merge request for this):
- don't commit the updated Makefiles together with other changes, do them as separate commits as otherwise such commits are harder to review
- please get rid of the added, but unrelated examples, they add *massive* noise to the commit
- also why did you remove the *.o files for the C and C++ tests (and some other binary files)? If a binary is commited then it's usually done for a reason
- separate commits that affect different functionality, e.g. the adjustment in comprsrc.CollectResourceFiles can be a separate commit; this also allows to better explain certain functionaliy, for example why the IndirectInits and related functionality is needed (this also applies to other parts)

Some specific remarks:
- in fpcp it is on purpose that the PCP file and the final module can reside in different directories; the user needs to supply the correct library and package search paths (for example for a installation on a *nix system the *.so files would reside in /lib/... while the *.pcp files would reside in /usr/share/...)
- in fpkg don't name the field fingerprint, but checksum to be consistent with the names of PPUs
- use symconst.suffix_indirect instead of literal '$indirect'
- in dynpkgtypes: the compiler is not restricted to PE, Mach-O and ELF, so the $else case should not be ELF
- most of the low level package loading functionality should be part of the System unit (that's why I moved the library manager there after all (and also for delayed imports)) and should be shared between all targets as much as possible; only the nitty, gritty platform specific parts should be part of a separate unit (except for Windows) to avoid pulling in the C library when not needed

One further thing that you did not think of: we need to rework the unit initialization/finalization mechanism to be reference counted. Take for example the following code structure:

ProgramFile.pp (does *not* use Classes)
- sysinit.pp

rtl.ppk
- system.pp
- classes.pp

pkgA.ppk
- unitA.pp (uses Classes)

pkgB.ppk
- unitB.pp (uses Classes)

Now ProgramFile obviously links against the RTL package at compile time. This means that the System unit of the RTL package will be initialized, but not the Classes unit, because ProgramFile does not link against that. Now the program loads PkgA which will lead to all units of PkgA as well as all units from other packages used by units of PkgA to be initialized (in this case the Classes unit from the RTL package). Now the program also loads PkgB which will also initialize all its units and those indirectly used; this means that the Classes unit *must not* be initialized again.
Now PkgA is unloaded. But that means the Classes unit *must not* be finalized yet, because PkgB (which uses the Classes unit as well) is still loaded.

This means that the unit initialization/finalization should be reworked to have a single entry point (currently a unit has several depending on whether it as an indirect initializer/finalizer, an initialization/finalization section and class constructors/destructors) and that should only be executed if its reference count is still 0 (for initialization) or reaches 0 (for finialization). The initializer/finalizer will also have the task of initializing/finalizing all used interface and implementation units.

With this the InitTable of the program will only contain those units directly (and automatically) used by the program. All other units will be initialized indirectly. Same with the UnitTable of the packages.

Since changing to this reference counting scheme (and thus essentially a depth first search of the unit tree) needs to a change in the initialization order the JVM and AVR targets (which don't use the typical InitTable scheme) need to be adjusted to have the same order generated at compile time.

Also as a further, somewhat related change: we should introduce a meta data type per unit which contains reference to the unit's RTTI, Threadvars, etc. This would also be the base for the RTTI units' GetTypes method and in the end each type's RTTI should have a reference to this meta data instead of a unit name like e.g. a class' RTTI currently has.

Please note that these comments are not yet fully conclusive, due to the extension of your commit. Once you've broken it down to easier digestable chunks more in depth discussion can be had.

Regards,
Sven

First some general remarks (especially if you want to work towards creating a merge request for this):

Probably off-topic, but:

If we (fpc) want to adopt this (or similar), I hope it's not in current 3.3.1. At least do it in a separate branch. Adding new and complex features to current main wil delay the moment when we "split off" a branch for the new stable compiler (4.0?) (feature freeze).
We're already waiting such a long time for a new release. (And it feels to me like adding new features gets more attention from the fpc-team than applying even relatively safe fixes for simple bugs. But that may be a personal frustration from my part. I _do_ know you all are devoting as much personal time you can, and then it's not illogical that you do what you like most...
And yes, I would help if I could, but I'm simply not qualified enough to be of meanungfull assistence for e.g. easing the work on preparing for 3.2.4...)

Bart,

I am going out of town for a few weeks and was hoping that people in the FPC and Lazarus community could give it a look and allow for some time to percolate on it. That means downloading and trying my implementation. It needs some small tweaks, and I need to provide some technical details about the memory structures and internals of what I added. I also am working on a Lazarus extension for builds with the dynamic compiler to make it easier to separate out an executable for its packages, allowing for packages and programs to be built apart from one another. This is possible right now with the correct compiler flags, but a normal user won't know how to manage that, so I have been working on a nice user interface in Lazarus to guide them through that process.

In the meantime, I have added an extension to convert forms and frames into controls and added to the Lazarus IDE in one step. This is especially useful with dynamic packages because you can do all this in a matter of a second withotu rebuilding the IDE. Also, iteration onchanges became an order of magnitude faster. I was able to finally fix small problems with my IDE theming system by jsut hitting compiler, and the IDE would udpate in a matter of a second while I fixed parts that were not being hit with themes correctly.

See:

https://www.getlazarus.org/codebot/reference/?page=codebot_themes_design

If I have time I might turn the theming into a component Windows and Linux users can place on their applications allowing them to theme the apps they write. As it is right now, I had to make some small adjustments to the IDE allowing style changes to be persisted through its own settings, rather than writing to those files in my own code.

Cheers,
Anthony