[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.
Regards,
Martin