[fpc-pascal] FPC with Firebird SuperServer

Jonas Maebe jonas.maebe at elis.ugent.be
Tue Jan 27 09:20:59 CET 2009

On 27 Jan 2009, at 10:07, Michael Van Canneyt wrote:

> On Tue, 27 Jan 2009, Jonas Maebe wrote:
>> On 27 Jan 2009, at 08:36, Bee wrote:
>>>> 2) Is there other advice the forum can offer (eg. does Classic  
>>>> remain a
>>>> reasonable choice, is SuperServer support planned, etc).
>>> I simply made a symlink name libfbclient.so in folder /usr/lib  
>>> which point to
>>> /Library/Frameworks/Firebird.framework/Versions/Current/Firebird  
>>> then
>>> everything worked fine (as in Linux).
>> You can do that on your own system, but it's not a solution for  
>> distributing
>> your application (/usr/lib is off-limits to third parties, and  
>> while you could
>> use /usr/local instead it's just hackish).
>> The main problem to me seems that the database units are all very  
>> rigid
>> regarding how the database library should be found. There appears  
>> to be no way
>> at all to say where the library is or may be located.
> This is not correct:
> function InitialiseIBase60(Const LibraryName : String) : integer;
> You can specify the full path if you want.

Good, then the problem should be easily solvable by using this  
function in combination with the information in the blog post that Bee  

> This is also not correct, there is a ibase60 unit which - contrary  
> to the
> ibase60dyn unit - is statically linked.

Thanks. That one should indeed work if you then add {$linkframework  
Firebird} to your main program.

> TSQLQuery and friends use the dynamically loaded version, for good  
> reason:
> they must be usable in circumstances where you don't know if the  
> library is
> present or not, as is the case in Lazarus, the database desktop and  
> whatnot.

I know, but if you know for sure that the library/framework is  
available (e.g., because you put it inside your application bundle on  
Mac OS X), then directly linking can be useful.

More information about the fpc-pascal mailing list