[Python-Dev] [C++-sig] GCC version compatibility

[Christoph Ludwig]

On Sat, Jul 09, 2005 at 12:08:08AM +0200, "Martin v. Löwis" wrote:
> David Abrahams wrote:
> >>When I looked into this problem I saw that configure in fact builds a test
> >>executable that included an object file compiled with g++. If the link step
> >>with gcc succeeds then LINKCC is set as above, otherwise CXX is
> >>used. Obviously, on my system this test was successful so configure decided
> >>to link with gcc. However, minimal changes to the source of the test program
> >>caused the link step to fail. It was not obvious to me at all why the latter
> >>source code should cause a dependency on the C++ runtime if the original
> >>code does not. My conclusion was that this test is fragile and should be
> >>skipped. 
> > 
> > 
> > Sounds like it.  I have never understood what the test was really
> > checking for since the moment it was first described to me, FWIW.
> 
> I'll describe it once more: *If* a program is compiled with the C++
> compiler, is it *then* possible to still link it with the C compiler?
> This is the question this test tries to answer.

The keyword here is "tries" - my bug report #1189330 exihibts that the test
fails to do its job. And looking at the test that's certainly no surprise:

configure writes the following conftest.cc on the disk (whitespaces added for
better readability):

  cludwig at lap200:~/tmp/python-config> cat conftest.cc
  void foo();

  int main() {
    foo();
  }

  void foo() {
  } 

This TU is compiled with the C++ compiler and then linked with the C compiler:

  cludwig at lap200:~/tmp/python-config> g++ -o conftest.o -c conftest.cc
  cludwig at lap200:~/tmp/python-config> gcc -o conftest conftest.o

Note that there is *no* reference to any symbol in another TU. The compiler
can detect that foo() won't throw any exceptions, that there is no need for RTTI
and whatever else the C++ runtime provides. Consequently, the object file
produced by g++ does not contain any reference to symbols in libstdc++.

However, python.c does reference a function from other TUs, in particular
extern "C" int Py_Main(int, char**). The following test shows that in this
situation you must link with g++:

  cludwig at lap200:~/tmp/python-config> cat conftest_a.cc
  extern "C" void foo();

  int main() {
    foo();
  }
  cludwig at lap200:~/tmp/python-config> cat conftest_b.c
  void foo() {
  }
  cludwig at lap200:~/tmp/python-config> g++ -o conftest_a.o -c conftest_a.cc
  cludwig at lap200:~/tmp/python-config> gcc -o conftest_b.o -c conftest_b.c
  cludwig at lap200:~/tmp/python-config> gcc -o conftest conftest_a.o conftest_b.o
  conftest_a.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
  collect2: ld gab 1 als Ende-Status zurück

(I ran this test with g++ 3.3.1, 3.4.2, and 4.0.0 with identical results.) The
reason is, I guess, that even though foo() is delared to have "C" linkage, it
still can throw a C++ exception. 

> >>If Python is built with --with-cxx then it should be linked with CXX
> >>as well.
> > 
> > 
> > U betcha.
> 
> Wrong. The test was introduced in response to complaints that Python
> unnecessarily links with libstdc++ on some Linux systems. On these
> Linux systems, it was well possible to build main() with a C++ compiler,
> and still link the entire thing with gcc. Since main() doesn't use
> any libstdc++ functionality, and since collect2/__main isn't used,
> one would indeed expect that linking with CXX is not necessary.

Of course, if you insist on this "dependency optimization" then you can try to
fix Python's configure.in by using the second test above. But I would still
not trust it to cover all configurations on all platforms supported by
Python. 

> >>(On ELF based Linux/x86, at least.) That leaves me wondering
> >>
> >> * when is --with-cxx really necessary?
> > 
> > 
> > I think it's plausible that if you set sys.dlopenflags
> 
> This has no relationship at all. --with-cxx is much older than
> sys.dlopenflags. It is used on systems where main() must be a
> C++ program for C++ extension modules to work (e.g. some Linux
> systems).

Can you provide a concrete examples of such systems? The explanation of
--with-cxx in the README mentions a.out. Are there other systems?

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html