[fpc-pascal] Re: linux: should we hard-code versioned or
unversioned shared libraries in our apps?
Michael Van Canneyt
michael at freepascal.org
Wed Aug 15 16:19:56 CEST 2012
On Wed, 15 Aug 2012, Reinier Olislagers wrote:
> On 15-8-2012 15:59, Graeme Geldenhuys wrote:
>> On 15 August 2012 14:39, Jonas Maebe <jonas.maebe-3RqwKoEL1alVsUKGZV2E3Q at public.gmane.org> wrote:
>>>> FCL-DB uses dynamic linking by default, and looks for the unversioned
>>>> shared library. So what specific Firebird version is the FCL-DB coded
>>> I have no idea, which is why I also said in my first reply:
>> Umm, so ideally the ibconnection.pp unit should really be split into
>> various units with version numbers in their names. That way we will
>> know to which Firebird version they are referring too.
>> eg: ibconnection.pp // old interbase only (eg: Delphi 7)
>> Include files could probably be used to reduce some duplication of code.
> OT: that would be useful for another reason.
> Firebird 3 will introduce the BOOLEAN datatype and other innovations
> (encrypted connections, etc).
> Interbase has had BOOLEAN support for a while now.
> It would be nice to be able to support new functionality without
> sacrificing the ability to connect to older clients.
That has nothing to do with dyn versus static linking.
You can perfectly detect which library version you are loading,
and enable/disable certain functions based on this.
Mysql is a different story in that the internals of the structures
change with each release, making it almost impossible to unite all
versions in 1 unit.
Firebird has a long tradition of keeping the API and structures
backwards/forwards compatible, thus obliviating the need for
different units for each version.
At least for firebird, there will be 1 unit, loading dynamically what
is available. If you want to load something else than the default,
you have been able to do so since day 1.
Contrary to Marco's belief, I am firmly convinced that this is the
best and easiest approach.
More information about the fpc-pascal