This is the mail archive of the
mailing list for the GCC project.
Re: Minimal GCC/Linux shared lib + EH bug example
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Martin v. L÷wis <loewis at informatik dot hu-berlin dot de>, "Ralf W. Grosse-Kunstleve" <rwgk at cci dot lbl dot gov>
- Cc: c++std-ext at research dot att dot com, gcc at gcc dot gnu dot org
- Date: Wed, 15 May 2002 21:16:23 -0700
- Subject: Re: Minimal GCC/Linux shared lib + EH bug example
--On Wednesday, May 15, 2002 01:07:02 PM +0200 "Martin v. L÷wis" <email@example.com> wrote:
> "Ralf W. Grosse-Kunstleve" <firstname.lastname@example.org> writes:
>> Once you guys have figured out what "the right" approach is, PLEASE
>> document it clearly and in a way that can be understood by a wider
> I think the message that can be understood by a wider audience is:
> don't use C++ for Python extension modules.
As someone knowledgeable about C++ implementations, and somewhat
knowledgeable about Python's implementation, I second this advice.
That might change if the ELF/C++/etc. semantics get better in the ways
that are being discussed, but at present, I will simply say that if
I were going to build a Python extension module, I would do it in C,
even though I generally find that I am more cost-effective when working
It occurs to me that another way to solve these problems is to change
the rules for loading modules, from the point of view of Python. The
whole point of using RTLD_LOCAL is to prevent name clashes between
Why not define that problem away?
If the rule was that, for example, all externally visible names in the
loaded modules had to be within namespaces that were assigned by some
naming authority, or otherwise consistent, then you could load modules
Yes, I know this is non-trivial, but if you want to use C++, it's the
practical solution over the medium term.
-- Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com