Hi,

I noticed that on newer Ubuntu Linux systems that the name of the Firebird shared library has changed for v2.x versions of Firebird Database Server.

----------------------------------
$ ls -l /usr/lib/libfbcl*
2009-08-24 12:06 /usr/lib/libfbclient.so.2 -> libfbclient.so.2.1.1 2008-11-19 20:09 /usr/lib/libfbclient.so.2.1.1
----------------------------------

It seems the SqlDB + Firebird code only looks for 'libgds.so' and 'libfbclient.so' giving the following error at runtime...

Can not load default Firebird clients ("libgds.so" or "libfbclient.so"). Check your installation.

Is there a way we can better handle this for Firebird v2.x is SqlDB? After all, Firebird v2.x has been out for quite some time now.

Or should be simply ignore this issue in SqlDB and make it the issue of the user? This option I do not like to much.

If FBLib, this was handled by looking for newest to oldest versions of shared library. Loading was done in if..else statements.

example
    // try v2.x library first
    if not successful loading of libfbclient.so.2 then
       // else try v1.x library
       if not successful loading of libfbclient.so.1 then
         // else try basic library name - no versions
         if not successful loading of libfbclient.so then
            // now user has a real installation problem

Regards,
- Graeme -

Op maandag 24-08-2009 om 13:02 uur [tijdzone +0200], schreef Graeme Geldenhuys:

Send a bug to Debian/Ubuntu/whoever makes that package.

There's no api-difference between firebird 1 and 2 clients. So this difference is bogus. Also the default Firebird-installations which you can download form the firebird-website adds the correct symlink.

Joost.

Hi Graeme

It seems the SqlDB + Firebird code only looks for 'libgds.so' and 'libfbclient.so' giving the following error at runtime...

With my last production experience with Firebird, libgds.so was the stubs to the old Interbase lib where Firebird derived from. libfbclient.so.x is backwards compatible to these stubs. I guess in newer releases of firebird, they are slowly but surely trying to get away from Interbase.

A firebird installation is supposed to provide symlinks for libfbclient.so and libgds.so to load the correct lib for the release. In most cases, the LD_LIBRARY_PATH environment variable is supposed to be set if you want your so's to be located automatically. It's something you need to set up yourself in most cases.

It would be nice though if fpc's api wrapper of libfbclient also allows you to set an absolute path to the API

On Mon, Aug 24, 2009 at 11:02 AM, Graeme Geldenhuys <

2009/8/24 Desmond Coertzen :

With my last production experience with Firebird, libgds.so was the stubs to the old Interbase lib where Firebird derived from. libfbclient.so.x is

The problem is easy to fix from my side, by simply manually creating a libfbclient.so symlink to libfbclient.so.2 - which I have done, and my programs now work.

I just thought it might be nice if SqlDB+Firebird support looked for a few possible shared library names instead of _only_ looking for libfbclient.so
But reading Joost's reply, I guess the answer is no.

Doing a search on http://packages.ubuntu.com, it seems that only the 'firebird2.0-dev' and 'firebird2.1-dev' packages include the symlink libfbclient.so. The standard firebird client and server packages only install libfbclient.so.2

Regards,
- Graeme -

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

En/na Graeme Geldenhuys ha escrit:

This is standard practice on debian, mandriva and probably other distributions.
The idea(if I'm not wrong) is that the bare .so file is only used by the linker at compile time, so you can install packages with various versions of the same library to be used by other binary packages (that only use the versioned .so file) but only develop for one (usually, but not always, the latest one) by installing just one -dev (or -devel in mandriva) package that just has the simlink to the corresponding versioned .so file, the headers and other files to be used by the linker (.a, .la I think).
So, in their view (and I cannot tell if it's right or wrong) a final program shouldn't look for the bare .so file but only depend on the versioned one. That way if you make a binary package, it usually will automatically (or manually if the packaging system isn't able to determine the dependency by analyzing the executable) depend on the correct version of the library package.

Bye