This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Minimal GCC/Linux shared lib + EH bug example
- From: loewis at informatik dot hu-berlin dot de (Martin v. Löwis)
- To: "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: 15 May 2002 19:31:34 +0200
- Subject: Re: Minimal GCC/Linux shared lib + EH bug example
- References: <200205151449.g4FEnC232866@boa.lbl.gov>
"Ralf W. Grosse-Kunstleve" <rwgk@cci.lbl.gov> writes:
> > I think the message that can be understood by a wider audience is:
> > don't use C++ for Python extension modules.
>
> Surely You're Joking, Mr. Loewis!
Only half-ly.
> As it stands, Linux/gcc3 is the only platform that does not do what
> we want. Are you sure it is helpful to tell people to "go away"?
For *your* application, only Linux/gcc3 fails to work. For any
compiler/platform combination, I could produce numerous cases that
won't work as many people may expect.
If you want a simple answer, you have to accept the one you I gave. If
you cannot accept this, you must accept that the issues are much more
involved.
> - Is the situation different if python is compiled and linked with a C++
> compiler (--with-cxx)?
Not on your platform. On other platforms, C++ extensions won't work at
all unless Python is compiled with C++ (AIX, with the system compiler,
is one of these platforms).
> - More generally: What are the issues when using dlopen in any C++
> program.
Too numerous to list in this message. They roughly group into the
following categories:
- constructor/destructor execution: may or may not execute at dlopen
time, block-static variables may or may not work correctly.
- duplicate definition of things, where things is one of
- virtual method tables
- typeinfo object
- template instantiations
- malloc heaps
- locales
- ...
- conflicting symbol spaces
- dynamic failures to resolve symbols
Regards,
Martin