On 08/04/2013 14:11, Holger Joukl wrote:
I have found a couple of references.
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html (see static-libgcc)
http://gcc.gnu.org/wiki/Visibility
Thanks, I'll need to look into these.
The proprietary lib is shared, right? linked to? shared? static?
Shared C lib, we compile a shared C++ lib linked to the C lib from the
vendor
C++ sources, which we shared-link the (shared) Boost.Python wrapper to.
Quoting from the manual:
There are several situations in which an application should use the shared
libgcc instead of the static version. The most common of these is when the
application wishes to throw and catch exceptions across different shared
libraries. In that case, each of the libraries as well as the application
itself should use the shared libgcc.
However, if a library or main executable is supposed to throw or catch
exceptions, you must link it using the G++ or GCJ driver, as appropriate for
the languages used in the program, or using the option -shared-libgcc, such
that it is linked with the shared libgcc.
Likely the C_lib.so is not linked to libgcc_s.so. Don't know if it's possible
to "extract" the objects from the shared .so. Maybe playing dirty with LD_PRELOAD?
--
Giuseppe Corbelli
WASP Software Engineer, Copan Italia S.p.A
Phone: +390303666318 Fax: +390302659932
E-mail: giuseppe.corbe...@copanitalia.com
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
