Compile Python 3.1.1 with --enable-shared

Question

This is a two pronged question... The context of the question is getting a good Python 3.1.1 build to use with building and running mod_wsgi. See this document for more information on why a shared library is a good idea.

What are the ramifications of building Python with --enable-shared?

I observe that when I build it WITHOUT --enable-shared, the python binary is ~ 16MB

-rwxr-xr-x 2 root root 1638104 Aug 17 12:29 python3.1

With --enable-shared, the python binary is 15K.

-rwxr-xr-x 2 root root   15860 Oct  5 22:34 python3.1

In general, what does that do to "normal" operations of python? Will all scripts still run the same? Any performance impact? Can you, or is it desirable, to have both (shared and static)?

Any ideas on how to solve this error cleanly?

Note: built on a clean RHEL 5.3 64 bit install.

After building Python 3.1.1 with ./configure --enable-shared, I get this error:

[root@test ~]# python3
python3: error while loading shared libraries: 
libpython3.1.so.1.0: cannot open shared object file: No such file or directory

I solved it by placing this symlink:

/usr/lib64/libpython3.1.so.1.0 -> /usr/local/lib/libpython3.1.so.1.0

Which seems quite hackish... Are there ./configure options that can be passed to cure this?

--

Thanks!

Answer 1

This is probably one for superuser.com but ok, I'll bite.

What are the ramifications of building Python with --enable-shared?

You get a binary that uses the dynamic loader to link with the libraries it needs, nothing wrong with that. When any of the libraries your binary depends on are updated, the next invocation of that binary benefits rather then the next build.

In general, what does that do to "normal" operations of python?

Nothing.

Will all scripts still run the same?

Yes.

Any performance impact?

If spawning python processes quickly is your only concern, static linking is a little bit faster.

Can you, or is it desirable, to have both (shared and static)?

Sure you can, but a dynamic binary does fine, no need for any static binaries unless you know you need it.

Any ideas on how to solve this error cleanly?

Edit /etc/ld.so.conf, add "/usr/local/lib" on a line of its own, run ldconfig

Are there ./configure options that can be passed to cure this?

Just guessing... --prefix=/usr

Answer 2

I ran into this issue myself, on a Fedora 64-bit system, and found a not so much an answer, but at least an explanation for myself:

This Python bug has been around since 2003, and still applies to 3.1: There is a --libdir flag for configure that should be able to set the library directory, but in reality it does nothing; the Python libraries will always install in "PREFIX/lib". The bug has a few developers chiming in on why this is the case (for the time being). So, in my case for Fedora, running:

./configure --enable-shared --prefix=/usr

I had to run

ln -s /usr/lib/libpython3.1.so.1.0 /usr/lib64/libpython3.1.so.1.0

after the installation to get it to work. So, yes it is a bit hack-ish, but it's the way the Python build works for the time being.