We have been using Mac OS X 10.5 XCode 311, Firebird 211 Classic 32 bit with FPC 224 (which contains the fix for the framework .dylib extension so that libfbclient.dylib can be located). This works with FPC, FlameRobin and RazorSQL. However, reading Firebird's recommendation that unless there is a good reason, SuperServer should be used we have attempted this conversion. Switching to SuperServer 32 bit, FlameRobin and RazorSQL continue to work - but FPC raises an exception. EInOutError : Can not load default Firebird clients ("libgds.dylib" or "libfbclient.dylib"). Check your installation. When the Framework is opened in the OS X library we confirm that libfbclient.dylib is no longer found (although the other 4 library files remain).

Questions
1) Can FPC work with Firebird SuperServer - if so, what configuration changes are required or does the FPC library required modification?
2) Is there other advice the forum can offer (eg. does Classic remain a reasonable choice, is SuperServer support planned, etc).

Thank you.
Regards,
Andrew Hall.

It can, and no change should be necessary.

2) Is there other advice the forum can offer (eg. does Classic remain a reasonable choice, is SuperServer support planned, etc). From the client perspective, there is no difference whatsoever whether

you are running superserver or classic. I use both.

The problem you are experiencing is an installation problem, not an architectural problem. For some reason, the FPC application fails to find the libraries. However, I have no idea why this happens. I'm not a Mac OS X expert, so I can't help with that.

As far as the 'recommendation' is concerned: for systems with multiple CPUs it is better to use Classic server, as Superserver can use only 1 processor. The upcoming version 2.5 of Firebird should remedy that.

Michael.

Michael Van Canneyt wrote

As far as the 'recommendation' is concerned: for systems with multiple CPUs it is better to use Classic server, as Superserver can use only 1 processor.

"... multiple CPUs" - Does that include the new multi-core CPU's?

The upcoming version 2.5 of Firebird should remedy that.

Excellent.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Andrew Hall wrote

1) Can FPC work with Firebird SuperServer - if so, what configuration changes are required or does the FPC library required modification?

We use Firebird SuperServer on our Linux and Windows systems. No modifications were required.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Yes. It uses 1 core.

Michael.

http://paulbeachsblog.blogspot.com/2008/03/where-is-libfbclientdylib-on-macosx.html

Questions 1) Can FPC work with Firebird SuperServer - if so, what configuration changes are required or does the FPC library required modification?

Yes, it can. I'm using both of them.

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).

HTH.

-Bee-

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. 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).

Jonas

This is not correct:

function InitialiseIBase60(Const LibraryName : String) : integer;

You can specify the full path if you want.

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.

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.

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.

All you'd need to do is include the unit, I suppose. The dlopen() should then probably return the already linked library ?

Michael.

Only if the name matches exactly. In case of a framework, the name of
the library inside the may be different.

Jonasx