Free Pascal Gets Runtime-Loadable Dynamic Packages in a Fork, Two Years After a Core Developer Listed the Gap

A developer who publishes as sysrpl has released full dynamic package support for Free Pascal and the Lazarus IDE, on a page at getlazarus.org that carries no version number and no date. The changes live in forked GitLab branches called "dynamic packages," not in a Free Pascal release.

The page says packages are built as shared libraries on Linux, Windows and macOS, and that a runtime can load, enumerate, search and unload them. That is the piece Sven Barth said on the fpc-pascal mailing list on October 28, 2024 was still missing.

What Barth said was missing

Barth wrote that compile-time use of dynamic packages was implemented and "in theory working" for the Darwin targets, the Windows targets and x86_64-linux, but "not yet enabled by default" because "the build system can not yet generate the packages required." He added: "What is missing is support to load additional packages at runtime." He also wrote that "Lazarus currently does not support dynamic packages."

The getlazarus.org page claims all three gaps are closed. The runtime library gets a DynPkgTypes.pas unit for reading package contents, plus calls to load, enumerate, search and unload packages while a program runs. The page says the runtime manages thread variables and dynamic types such as strings and dynamic arrays across programs and packages.

What changes in Lazarus

For a Lazarus user the practical change is the installed-package workflow. The page says adding or removing a package no longer needs a full IDE rebuild. Changed packages are rebuilt at startup with a progress window, installed packages can be recompiled and their controls updated "in a second or two," and several packages can be installed at once.

It also lists a Packages window that lists the last packages you opened, a way to restrict a package to a platform or widgetset, and a command to turn a form or frame into an installable control.

The screenshot shows Lazarus 1.0 from 2012, used here only to show the IDE the page is talking about. The page itself does not say which Lazarus release the new workflow was built against.

The restrictions on the page

Every restriction below appears on the page itself.

Restriction	What the page says
Unit names	A unit cannot share its name with its package, and unit names must be unique across packages
Package source	The source file gets "Package" appended to its name
Size	Dynamic packages are larger than ordinary shared libraries
Stripping	Stripping a package removes the metadata it needs
macOS	Builds are difficult to produce; the page asks for donated M1 Macs

Packaging questions are live elsewhere too: PyPI wheels carry binaries nobody can tie to their source, and Lean 4.35 ships a cross-checked kernel. The uniqueness rule is the one that will bite a plugin author: two plugins that each ship a unit named Utils cannot be loaded together.

What is not on the page

The page gives no Free Pascal or Lazarus version, no release date and no timing for loading a package. It sends feedback to a GitLab issue tracker and to a forum where a moderator approves new accounts. It does not say whether the work has been offered to the Free Pascal team.

Because the code sits in forks, a Linux distribution or a Lazarus installer cannot carry it until it is merged or someone builds from the branches. I did not find a merge request in the pages I read.

The next thing to look for is that merge request, or a reply from the Free Pascal core team on whether the runtime-loading design matches what Barth described in 2024.