[Python-Dev] Why is python linked with c++?

"Martin v. L÷wis" martin@v.loewis.de
Wed, 09 Jul 2003 23:49:28 +0200

Skip Montanaro wrote:

> I think you misunderstood what I wrote.  As far as I can tell, ccpython.cc
> is not compiled when building python.exe on my Mac.  Accordingly, the link
> step should use gcc, not c++.

This is uncertain. There is a configuration mechanism that determines 
whether you need the C++ compiler to link, and it comes to the 
conclusion that you do. It might be a bug that it not also tries 
compiling ccpython.cc, but so far, nobody has complained that it should

> I think you need different check than the usual command completion to
> determine whether -Kthread should be given or not.  If you can suggest some
> ways to do this with configure macros I will take a stab at it, but I don't
> understand autoconf/configure well enough.  I suspect doing something like
>     c++ -Kthread ... 2>&1 >/dev/null | egrep 'unrecognized option'
> is too fragile, but that may be the only sort of solution available.

It's not necessary to understand autoconf at all. Tell me what algorithm
*you* use to determine that -Kthread is a bad idea, and I tell you how 
to translate it into autoconf.

The current algorithm is not only supposed to find out whether -Kthread 
is available, but also if it has any effect - i.e. whether providing 
that option indeed enables the threads library which wouldn't be enabled 
without it. For some reason, it determines that -Kthread is supported 
and has the desired effect. Study config.log to find out what tests it 
performs, and why it then concludes that -Kthread is a good thing.

> I took a quick look at a RH8 machine.  Its gcc doesn't understand -Kthreads
> either.  Maybe it's a safe assumption that if $CC == gcc -Kthreads should
> not be given.

Hmm. On my machine, it concludes that it should use -pthread, which is 
supported and has the desired effect. A platform expert should be able 
to tell what to use on your system.