shared library

(here if I say shared library I mean both .so as .dll, unless I really say "unix shared library" or "dll")

Currently there are a lot of Shared libraries bug reports. However, to my knowledge there is no real documentation about how shared libraries work in combination with FPC. That is both how shared libraries work now, how they should work, and how Delphi treats them.

Let's start with a simple sketch of what forms Delphi supports, because we will of course try to be as compatible as multiplatformwise reasonable.

Delphi

Delphi to my knowledge knows three (or four) ways of dynamic linking.

• create a standalone shared library. (compiling a library unit without "runtime packages" selected).
  • This means the RTL will be linked into the shared library
  • This also means the memory manager will be its own island. Using automated types in functions that communicate with it is not possible.
  • Classes use is not possible. (both program and shared library have own copies of the VMT)
• create a standalone shared library. (compiling a library unit without "runtime packages" selected), but while using unit sharemem
  • This means the RTL will be linked into the shared library
  • But the memory manager is switched to COM compatible. This means other components/programs that also switch their memory manager to sharemem can call functions that use automated types. (because it doesn't matter who returns the block to the COM memmanagement system).
  • Note that afaik the COM memory manager is quite slow. This road is probably not desired unless you really want to mess with COM.
  • Classes use is not possible. (both program and DLL have own copies of the VMT)
• Packages These are shared libraries for which all dependancies on pascal level are known (which units they contain and depend on), and can be treated as parts of the main program that reside in a DLL.
  • The RTL is in a separate package(DLL), and both the mainprogram and package use it. Therefore there is only one copy of any unit including system.
  • This also means there is only one memory manager (at least for the mainprogram and the packages it uses. IOW shared libs that are not a package can still use an own RTL and memory manager)
  • a package can only depend on units in its own package or in other packages.
  • because no units are duplicated, there is only one copy of each VMT, making classes use transparent.
  • Probably packages can also switch to sharemem, making it compatible with other sharemem using systems. Some way must be found to initialise sharemem as early as possible though (does Delphi do this? Possible test for this is to pass an ansistring created in a init section of a unit in a package to a different sharemem using shared lib that is not a package) T.B.D.

Besides these, Delphi can also generate dlls that are ActiveX components. T.B.D.