Problem building python 2.7 with --enable-shared

[Marten Lehmann]

I digged into this one step further:

I compared the output of configure and make. For configure, there is no 
change. But for make, I found out something, that I didn't expected:

When configure is called with a prefix to a location, where a valid 
python installation already exists, it uses these locations for gcc, 
although it shouldn't (we are about to compile a clean, brandnew python 
version, so why should it include parts of an existing python 
installation?).

Additionally to the default include paths

gcc [...] -I. -IInclude -I./Include -I/usr/local/include 
-I/usr/src/redhat/BUILD/Python-2.7/Include 
-I/usr/src/redhat/BUILD/Python-2.7 [...]

the path of the existing Python installation is added:
-I/test/python2/include

And additionally the default library paths and libs

gcc [...] -L/usr/local/lib -L. -lpython2.7 [...]

the path of the existing Python libs is added:

gcc [...9 -L/vrmd/python2/lib

So linking to python2.7 during make doesn't link to the freshly build 
library, but to the existing in the system. And at least in my case, 
where I'm switching from a python installation without --enabled-shared 
to a new version including --enable-shared, this causes serious problems:

/usr/bin/ld: /vrmd/python2/lib/libpython2.7.a(abstract.o): relocation 
R_X86_64_32 against `a local symbol' can not be used when making a 
shared object; recompile with -fPIC
-/vrmd/python2/lib/libpython2.7.a: could not read symbols: Bad value
-collect2: ld returned 1 exit status

Is there any option I missed in configure or any variable that I might 
set to correct this? Or should a file a bug to the python developers? 
Deinstalling python before compiling or renaming the python directory is 
not a good solution.

Kind regards
Marten