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. 

Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

configure 1.473
configure.in 1.486
NEWS 1.1331
configure 1.462.2.9
configure.in 1.475.2.9
NEWS 1.1193.2.70