This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minimal GCC/Linux shared lib + EH bug example




--On Wednesday, May 15, 2002 01:07:02 PM +0200 "Martin v. L÷wis" <loewis@informatik.hu-berlin.de> wrote:

> "Ralf W. Grosse-Kunstleve" <rwgk@cci.lbl.gov> 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
>> audience.
>
> 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
in C++.

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
modules.

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
with RTLD_GLOBAL.

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                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]