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.

> And there also appears
> to be no way either to link to the Firebird client libaries directly (e.g. by
> adding {$linkframework Firebird} to your main program and embedding the
> framework in your application bundle -- well, you can do that, but the
> firebird units still won't work because they insist on having the library
> available under a particular name and findable using dlopen).

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

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.

Michael.
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply via email to