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
--
http://mail.python.org/mailman/listinfo/python-list
