On Mon, 12 Dec 2005, Nuno Lopes stipulated: > Update: I've tried to compile some sample sources, but linking has failed with: Yeah, linking two libraries using incompatible versions of libstdc++ will be tricky, requiring linking against *both* copies using -Bgroup. (It's best to experiment using little testbed shared libraries exporting symbols of the same name, printing out different things from each shared library, until you grasp how -Bgroup works. It can be counterintuitive.) Note that this will have other (nasty) side-effects; notably exception catches of exceptions thrown from the Sony API will fail, and types within the Sony API will appear different to apparently-identical types outside the Sony API. To describe this as `unsupported and risky' would be like describing the ocean as `slightly damp' or the recent oil fire in Hertfordshire as `a little warm'. Your *safe* options are to get Sony to provide a later version of this library --- or, better, a version with a C interface, so that you can be sure that no libstdc++ objects leak out of it --- or to stick with GCC 3.3.x. (If the Sony library only *has* a C interface, the -Bgroup trick should work, I think.) > And it continues with a couple more errors about that default_alloc > function and std::list. Isn't there a workaround, so that I can link > the objects with the old lib? You have to link the Sony API with the old lib, and your new code with the new lib, using -Bgroup to avoid clashes. -- `I must caution that dipping fingers into molten lead presents several serious dangers.' --- Jearl Walker
