When building Python on Linux, there is a configure option called --enable-shared, so I will explain it and give you some tips.
I've given Python as a concrete example, but I think most of the content is common to other languages and libraries.
If you do not specify this option, you will have an executable file called python and a library file called libpython2.7.a (for Python 2.7) as the main binary files.
If you add --enable-shared, a shared object for dynamic link called libpython2.7.so is also generated, and python will dynamically link this shared object.
Linux distributions such as Debian usually build Python with this option. This is because many programs are built to use Python, and if you link libpython2.7.a directly, you will have to update all of them when you upgrade Python.
I don't recommend --enable-shared because if you're building Python yourself, this advantage doesn't really come into play, but rather can get in the way of people who want to use multiple versions in parallel. Unless you want to use shared objects for some reason, you don't have to read the rest.
When a python executable file or a program that links Python as a library, such as mod_wsgi, becomes dependent on libpython2.7.so, the program you are running will depend on libpython2.7.so. There is a possibility that you will not use.
For example, if you build and install with --prefix = / usr / local / Python-2.7.3, you can run /usr/local/Python-2.7.3/bin/python to set and environment variables. Depending on the situation, /usr/lib/libpython2.7.so or /usr/local/Python-2.7.2/lib/libpython2.7.so may be used.
You can use the environment variable LD_LIBRARY_PATH to specify the location of the library to be loaded preferentially, but if you are using multiple versions of Python in parallel, it is troublesome to switch the environment variable yourself. If someone else is using the same server, that person can be confused.
Maybe this is a straightforward approach.
The dynamic linking side, such as the python executable file, will record the location of the linking libpython2.7.so with the full path.
To set the rpath, it's easy to specify LDFLAGS when configuring.
$ ./configure --prefix=$HOME/python27 --enable-shared \
LDFLAGS=-Wl,-rpath,$HOME/python27/lib
The only downside to using rpath is the portability of copying the entire Python to another directory with cp -r etc. and rewriting the shebang in the script in bin /. In virtualenv, if libpython2.7.so is in the original location, it will continue to work, so there is no problem, but if you use virtualenv, you do not know how long the old version of Python is used and you do not want to erase it, so copy the whole thing It is not recommended for people who want to use it.
If you need a shared object for some purpose, but the python executable doesn't need to dynamically link it, there is a way to link libpython2.7.a when building python. .. To do this, open the Makefile after configure and
BLDLIBRARY= -L. -lpython$(VERSION)
Where it is
BLDLIBRARY= libpython$(VERSION).a
I will rewrite it to.
The Debian package python seems to be built in a similar way, with libpython2.7.so statically linked to libpython. It seems that the shared object is PIC and the performance was poor. (This is also the reason why you can't use Python 2 and 3 in vim at the same time)
Recommended Posts