[fpc-devel] FPC dynamic libraries

Jonas Maebe 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 mailing list