> I installed FirebirdCS-1.5.0.3780-RC6.i686.rpm on a system running
> RH8+updates and was able to reproduce your segfault. I did, however, get a
> different stack trace (below). This may be because I recently installed gdb
> 6.0 on this system to get some debugger fixes. In my case, the segfault is
> coming from the -lstdc++ library delete operator, which makes more sense:

Yes that does make more sense. Especially since qt-mt doesn't even define
operator delete[]! I figured gdb must be getting something wrong in the back
trace.

> So, whichever library gets linked into your application first defines the
> delete operators -- the order of libraries given to the linker is
> important. So, as you already know, link with -lgds as the first library in
> your link command and you shouldn't see segfaults.

The problem I have is that what I'm really going is loading libgds.so
dynamically at runtime using dlopen which means I have no control over whats
already linked in. So it looks like if my program links with stdc++ then I
can't dynamically load libgds.so but I think most C++ programs will do this
so it won't ever work.

Also it sounds like the client library isn't even supposed to be using the
memory pool and also the valgrind output shows that things aren't right even
when I do link things in the right order. I think things are rotten in here
and need to be fixed!

--
Brad Pepers
brad@...