mod_python在 RHEL/CentOs 64 位编译上的问题

mod_python在 RHEL/CentOs 64 位编译上的问题

I just went through the fairly painful exercise of compiling mod_python 3.3.1 on a 64-bit RHEL 5 server. RHEL 5 ships with Python 2.4.3 and mod_python 3.2.8. I needed mod_python to be compiled against Python 2.5.1. I had already compiled and installed Python 2.5.1 from source into /usr/local/bin/python2.5. The version of Apache on that server is 2.2.3.
I first tried this:

# tar xvfz mod_python-3.3.1.tar.gz

# cd mod_python-3.3.1

# ./configure --with-apxs==/usr/sbin/apxs --with-python=/usr/local/bin/python2.5

# make

...at which point I got this ugly error:

/usr/lib64/apr-1/build/libtool --silent --mode=link gcc -o mod_python.la \

-rpath /usr/lib64/httpd/modules -module -avoid-version    finfoobject.lo \

hlistobject.lo hlist.lo filterobject.lo connobject.lo serverobject.lo util.lo \

tableobject.lo requestobject.lo _apachemodule.lo mod_python.lo\

-L/usr/local/lib/python2.5/config -Xlinker -export-dynamic -lm\

-lpython2.5 -lpthread -ldl -lutil -lm

/usr/bin/ld: /usr/local/lib/python2.5/config/libpython2.5.a(abstract.o):

relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object;

recompile with -fPIC

/usr/local/lib/python2.5/config/libpython2.5.a: could not read symbols: Bad value

collect2: ld returned 1 exit status

apxs:Error: Command failed with rc=65536

I googled around for a bit, and I found this answer courtesy of Martin von Loewis. To quote:
It complains that some object file of Python wasn't compiled
with -fPIC (position-independent code). This is a problem only if
a) you are linking a static library into a shared one (mod_python, in this case), and
b) the object files in the static library weren't compiled with -fPIC, and
c) the system doesn't support position-dependent code in a shared library

As you may have guessed by now, it is really c) which I

blame. On all other modern systems, linking non-PIC objects

into a shared library is supported (albeit sometimes with a

performance loss on startup).



So your options are

a) don't build a static libpython, instead, build Python

with --enable-shared. This will give you libpython24.so

which can then be linked "into" mod_python

b) manually add -fPIC to the list of compiler options when

building Python, by editing the Makefile after configure has run



c) find a way to overcome the platform limitation. E.g. on

Solaris, the linker supports an impure-text option which

instructs it to accept relocations in a shared library.



You might wish that the Python build process supported

option b), i.e. automatically adds -fPIC on Linux/AMD64.

IMO, this would be a bad choice, since -fPIC itself usually

causes a performance loss, and isn't needed when we link

libpython24.a into the interpreter (which is an executable,

not a shared library).



Therefore, I'll close this as "won't fix", and recommend to

go with solution a).

So I proceeded to reconfigure Python 2.5 via './configure --enable-shared', then the usual 'make; make install'. However, I hit another snag right away when trying to run the new python2.5 binary:

# /usr/local/bin/python

python: error while loading shared libraries: libpython2.5.so.1.0: cannot open shared object file: No such file or directory

I remembered from other issues I had similar to this that I have to include the path to libpython2.5.so.1.0 (which is /usr/local/lib) in a ldconfig configuration file.
I created /etc/ld.so.conf.d/python2.5.conf with the contents '/usr/local/lib' and I ran

# ldconfig

At this point, I was able to run the python2.5 binary successfully.

I then re-configured and compiled mod_python with

# ./configure --with-apxs=/usr/sbin/apxs --with-python=/usr/local/bin/python2.5

# make

Finally, I copied mod_python.so from mod_python-3.3.1/src/.libs to /etc/httpd/modules and restarted Apache.

Not a lot of fun, that's all I can say.