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.)
But I supposed that compiling it with proper -fabi-version would do the
trick..
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.
We aren't using exceptions, as well as Sony's lib.
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.
:) I couldn't find much documentation about it either.
(If the Sony library only *has* a C interface, the -Bgroup trick should
work, I think.)
Nop, sony's lib is C++ only. We even have to extend some classes that are
provided by them.
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.
So, resuming:
1. compile libstdc++ from gcc 3.3.6 (can I compile the lib alone?)
2. compile gcc & libstdc++ from gcc 4
3. link sony's lib with 1. (how?)
4. link our code with 2. (how?)
5. link both 3. and 4. with the -Bgroup trick together (how?)
BTW, and what if I replace the libstdc++ that comes with gcc 4 with gcc
3.3's lib? Shouldn't it work?
Thanks for your attention,
Nuno
