[fpc-devel] FPC dynamic libraries
jonas.maebe at elis.ugent.be
Wed Feb 7 21:56:54 CET 2007
On 07 Feb 2007, at 21:45, Mattias Gaertner wrote:
>> In principle you should be able to do it with "make shared" in the
>> respective directories. But I would strongly recommend against doing
>> that, since the interface is by no means stable and consequently
>> programs compiled against both newer and older rtl/fcl's are very
>> likely to break if they use a different rtl (and possibly fcl, since
>> the fcl also uses rtl functionality).
> That's a general problem with libs, isn't it?
Yes, but especially with libraries where the developers have not
committed to maintaining backwards compatibility with a particular
interface and which are often changed in an ad hoc fashion. The main
problem is probably that we mix both general and compiler-specific
stuff in the system unit. It should probably be split into something
like gcc's libgcc.a (which contains compiler-specific helper
routines) and the system's libc dynamic library (system and generic C
language support) before the rtl is ever distributed as a shared
> We need a version system.
That's not something "we" need, but which most OS'es need (and don't
provide, except for hacks like symlinks or different filenames).
Moreover, it doesn't really solve much unless you like having 20
different versions of the same shared library on your system (which
would more or less defeat the purpose of saving space, although it
could still save memory if more than one FPC program is running at
the same time).
What problem do you want to solve with having a shared library? The
complaint that Lazarus programs are too large? Personally, I think
switching to shared libraries will at this time introduce a lot more
complaints that it will solve (and not because of a lack of a
versioning system, but simply because the interface isn't anywhere
near stable enough imho).
More information about the fpc-devel