On 5 Apr 2005, dave fournier suggested tentatively:
> As for the g++ in the command line it was just to avoid having to
> write -lstdc++ since I am linking c++ code. However it
> gave me the thought that the stdc++ might get linked
> before the -Xlinker -static took effect so I changed to
>
> gcc ...... -shared -o nbmm.so -Xlinker -static .......... \
> -lstdc++
>
> and it did change the size of the library, but it still crashed.
As I understand it, statically linked shared libraries are dicing with
death. The implementation of malloc(), among other things, has changed
somewhat since the glibc version in RH8 (2.2.x?) and that in FC2: so
you've got several competing incompatible visions of the memory arena
there. That just isn't going to work. Link shared libraries dynamically,
and build them on the oldest system you will be needing it to run on (as
glibc guarantees upward but *not* downward binary compatibility).
This is even ignoring the C++ ABI changes which are likely killing you:
C++ code built with the version of GCC shipped with RH8 and that built
with the version shipped with FC2/FC3 simply aren't compatible, and you
can't run C++ code built with both compilers in the same process and
expect anything more than an unceremonious crash.
--
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
--- Peter da Silva
