A build of Python 2.4.1 on a i686-pc-linux-gnu system with
GCC 4.0 failed. configure set `LINKCC=$(PURIFY) $(CC) '
even though main() was compiled with g++ and you cannot
lin C++ object files with the C compiler on this platform (Bug
#1189330).
There was some discussion on python-dev that on some
platforms (notably Linux/ELF) the C++ compiler is
unnecessarily used to build Python which makes the python
executable depend on this particular compiler version's C++
runtime library. This patch does *not* address this issue; it
keeps the criticized behaviour but fixes configure.in such
that make does not fail anymore on above mentioned
platform. (I will try to come up in the next weeks with a patch
for the main trunk that addresses the - on some platforms -
needless dependency on the C++ runtime.)
In 2.4.1, configure compiled a single source file with the C++
compiler and tries to link it with the C compiler. Apparently
the improved optimizer of GCC 4.0 realized that in this
simple test program all symbols from the C++ runtime could
be omitted whence linking with the C compiler succeeded.
The new test generates two source files that more closely
resemble the situation with ccpython.cc: main() calls a C
function in another translation unit. main() is compiled with
the C++ compiler, the C function with the C compiler. Only if
the resulting object files can be linked into an executable by
the C compiler then configure sets 'LINKCC=$(PURIFY)
$(CC)'.
I tested the patch with GCC 4.0 and GCC 2.95.2 on
i686-pc-linux-gnu.
|