[fpc-pascal] Re: linux: should we hard-code
versionedorunversioned shared libraries in our apps?
Marco van de Voort
marcov at stack.nl
Wed Aug 15 20:18:29 CEST 2012
In our previous episode, Michael Van Canneyt said:
> > I don't see what is wrong with that. You get a nice exception when you try
> > to load a different library than the one that is alread loaded. But if I
> > want to make an app that works with embedded firebird or firebird client
> > (user selectable at any time) that have completely different settings (user,
> > password, database, etc), what is I wrong with creating 2 instances in the
> > OI and connect only one at the time?
> IMHO that would be a total waste:
> Since you'll have to store username/password/db file anyway in some
> form of user settings, you might as well store the library name as well.
I might be wrong, but if Zeos behaviour is any comparison, I think this is
all used designtime too?
On a development system one can assume that the libfbclient symlink is
there, and that is about the only certain point in this whole mess.
Note that currently also multiple names are tested for some client libs.
(e.g. fbembedded). That functionality should persist.
And contrary to user apps with the most likely _current_ name, inserting a
call on startup is much more annoying for Lazarus
> Because only 1 library can be loaded for each type of connection:
> the entry points are global.
> What you suggest implicates keeping a reference count, unloading,
> and then reloading.
> Ivo Steinmann tried implementing that once, and all his efforts
> were undone because it gave too much problems (specially the
> unloading if I recall correctly).
And IMHO this all reeks of that. (dll name in component). Sounds "easy",
but it doesn't really solve anything.
More information about the fpc-pascal