At 03:14 AM 5/01/2004 +0000, you wrote:

> >
> > One is that you shouldn't have tried to "upgrade" from SS to CS.
>What you
> > probably have now is a mish-mash of scripts and symlinks pertaining
>to both
> > and a Merry State Of Confusion. The architectures are quite
>different -
> > you need to uninstall SS before installing CS.
> >
>
>Yikes!!! Fortunately, this is all happening on a test box. I didn't
>realize you could uninstall Firebird, I've always just picked out the
>pieces. I've never, ever seen rpm --erase <package> work. Always
>says <package> not installed, I just assumed it's a permanent rpm
>bug.

You should find an uninstall script in the /bin directory. AFAIR, you have
to shut down the server first or it won't run. That's also going to be the
case if you use rpm -erase. The rpm packages were a bit flaky. I
understand that rpm -erase will work properly with the RC 8 rpm
installation though.

>I *had* to install CS, because I was upgrading php4, and
>apparently you can't build php4 using the Firebird SS libraries. No
>problem with php4 once I installed CS RC8.

Fair enough.

>So far, the most major problem I've encountered when switching back &
>forth between CS & SS is that kinterbasdb (a python package) must be
>deleted, then re-compiled & installed. Something about fbclient.so
>(SS) vs. fbembed.so (CS).

Yup, they are very different animules. It's OK to use fbclient.so to
connect to Classic (recommended, if there is threading involved) but you
can't use fbembed.so with SS at all. It's designed for the
one-process-per-connection model of Classic and simply can't work with the
threaded connection architecture of SS. The installers for both SS and
classic will symlink the "correct" client lib as libgds.so. I guess your
mixed-up symlinks might be causing A Few Little Difficulties, though less
so than if you had "upgraded" from CS to SS!! Old symlinks are probably
pointing to /usr/local instead of /opt. Maybe also you have both xinetd
and ibserver polling on port 3050. Needs work, I think...

/h