5

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!

Improve this question

3 Answers 3

Reset to default
8

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

Improve this answer
2
  • Without --enable-shared, readline works in interactive mode. With --enable-shared, readline does not work in interactive mode. Any ideas?
    – gahooa
    Oct 8, 2009 at 3:43
  • there might be memory implications on using python without --enabled-shared with some libraries, i.e. modwsgi: code.google.com/p/modwsgi/wiki/…
    – ashwoods
    Nov 29, 2011 at 11:07
3

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.

Improve this answer
0

For anyone coming back to this, this is the correct solution:

Edit /etc/ld.so.conf or create something in /etc/ld.so.conf.d/ to add /usr/local/lib and /usr/local/lib64. Then run ldconfig.

Improve this answer
2
  • 1
    Not always. Sometimes it is more appropriate to set LD_RUN_PATH environment variable to directory location when building things so that path is embedded in executables. At other times more appropriate to set LD_LIBRARY_PATH environment variable at runtime. Adding non standard directories into /etc/ld.so.conf not always viewed as a good idea.
    – Graham Dumpleton
    Aug 11, 2012 at 4:59
  • Chances are you want /usr/local/lib[64] in your LD path, because of what /usr/local is. That it isn't by default in some distributions is perhaps a bit of an oversight. Check out the FHS if you don't understand what I'm talking about, here.
    – draeath
    Aug 12, 2012 at 5:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .