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
referenced.
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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
