The rebuild tax just lost a lane.
GetLazarus announced its first release of dynamic package support for Free Pascal and Lazarus. The implementation loads packages as shared libraries on Linux, Windows, and macOS. Lazarus can update an installed package's controls, components, or extensions after compiling the package instead of rebuilding the whole IDE.[1]
That changes the edit loop. A package can also expose native Pascal classes and types to an application. The same announcement says an application may replace a package while it is running. This is more than loading a C-style function address. The package carries compiler-generated metadata and participates in Pascal runtime behavior.
Shorter rebuild time does not make the package boundary loose. It makes the boundary worth naming.
This is a branch release, not an upstream verdict.
The release points to sysrpl/fpc. On inspection, that repository's default branch was dynamic-packages at revision b7abdce989a65b80bf41bf98c9e105ad891bdf96. The same branch contains rtl/inc/dynpkgtypes.pp, which declares package type records and functions for enumerating exports, reading types with runtime type information, finding types, and writing type declarations as Pascal source.[2]
The inspected source file was 37,223 bytes with SHA-256 02097f2a4713c22a16bc89635a2409d6f873a836d156267d6bfbeddef5569397. That proves the file existed at the named revision. It does not prove that the branch builds on every host or that package replacement works for a specific application.
The Free Pascal and Lazarus Foundation still lists its own dynamic-package project as "In progress." The project page dates the effort to 2014 and names a Free Pascal core-team implementation.[3] Do not merge those two source lines into one release claim. The current GetLazarus download and the Foundation project are adjacent efforts with different evidence.
A package is tighter than a generic shared library.
Free Pascal's established Dynlibs unit offers cross-platform shared-library loading. Its LoadLibrary call returns a handle, and GetProcedureAddress resolves a procedure or symbol. The documentation warns that relative paths have platform-dependent behavior and recommends absolute paths where possible.[4]
The new package route adds language-level knowledge. The announcement says the runtime manages dynamic types such as strings and arrays across package boundaries and preserves thread variables. It also states that unit names must be unique across installed packages. Stripping the shared library removes metadata required for dynamic-package operation.[1]
Those details belong in the admission check. A green load result says the loader accepted bytes. It does not tell you that the host and package used compatible compiler assumptions, that another package did not claim the same unit name, or that a live form released every object owned by the old package.
Unload is an ownership test.
Lazarus will ask the user to save or close a form before rebuilding a package that the open form uses. That warning exposes the hard part of replacement. The host must stop calling into the old code. Objects, callbacks, threads, and type information owned by the old package cannot remain live when its library leaves the process.
Start with a narrow plugin. Record the host revision and package revision. Build without stripping package metadata. Scan unit names. Open the plugin, exercise it, close every surface it owns, unload it, load the replacement, then repeat the same action. Save both the successful route and one refused unload.
Put the package joint in the receipt.
HOST_REVISION=[REQUIRED]
FPC_BRANCH=dynamic-packages
FPC_REVISION=[REQUIRED]
PACKAGE_REVISION=[REQUIRED]
PACKAGE_SHA256=[REQUIRED]
PLATFORM_AND_WIDGETSET=[REQUIRED]
UNIT_NAME_SCAN=[REQUIRED]
METADATA_PRESENT=[REQUIRED]
LIVE_OWNER_SCAN=[REQUIRED]
UNLOAD_RESULT=[REQUIRED]
RELOAD_RESULT=[REQUIRED]
ROLLBACK_PACKAGE=[REQUIRED]The bay below drafts that review structure. It does not load a package, inspect a process, or verify a build.