[fpc-devel] FPC dynamic libraries

[Michael Van Canneyt]

On Thu, 8 Feb 2007, Bogusław Brandys wrote:

> Michael Van Canneyt wrote:
> > 
> > On Thu, 8 Feb 2007, George Birbilis wrote:
> > 
> > > > > > 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).
> > > > If I understand well what you mean, Vista has versioning of that kind,
> > > > you can ask to see older versions of any file and restore the one you
> > > > want. A small caveat is that for files that don't exist currently
> > > > anymore (deleted) there's no GUI to get them (or one I haven't spotted
> > > > yet) and you need to make a dummy file with same name, then right click
> > > > it and go to Properties, then ask for the older versions (there's a
> > > > special tab for that on the dialog). Not sure if the Basic version of
> > > > Vista has this functionality available (I tried it with Vista Ultimate)
> > > If you meant having many libs of different version exist side-by-side,
> > > .NET
> > > runtime supports it, but Win32 itself doesn't
> > 
> > Most unixes also have it. The point is that it kind of defeats the purpose.
> > Having 20+ libraries called fpcrtl-xyz.dll (or fpcrtl.so.x.y.z on unixes)
> > defeats the purpose of a shared library: saving disk and (more importantly)
> > memory space by factoring out common code. 
> > If we'd know that the fpcrtl.so (or .dll) interface will stay the same in
> > the next 5 years, it makes sense to distribute this. Since the interface
> > changes
> > still wildly, it's a bad idea.
> > 
> > Look at Delphi packages: as soon as the interface of a package changes,
> > you must re-compile all the binaries that use it. The same would be true for
> > FPC. I can assure you this is a major headache when distributing apps.
> > 
> > Michael.
> 
> Is that so hard to use version system for rtl libraries ? I think that most of
> Lazarus end users will work with one fpc version and no other.

I also tend to think so.

> 
> Lazarus developers still need fpc SVN and here is required a way to fast
> rebuild lazarus with fpc rtl which is nothing more that we are doing all the
> time now ;-) End users sometimes will need to rebuild lazarus and fpc also if
> some critical bugs are fixed in fpc but : is it something extraordinary  ?
> 
> 
> Am I missing something ?

No. Your reasoning seems correct to me. Like I said: you need a versioning
system. No big deal, we don't release official versions so often.

It just means you cannot mix the latest FPC with an 'official' lazarus release 
so easy. But my guess is that end users will not be so adventurous... :-)

I also don't upgrade my Delphi so often, exactly for this reason.

Since recompiling and loading custom packages will use the installed version 
of the libraries, there is no problem whatsoever: the versioning will be 
correct out of the box, since the IDE will point to the correct LCL packages...

Michael.