Sharing Python installation between architectures

Paul Smith paul at mad-scientist.net
Sun Nov 17 10:46:32 EST 2013


On Sat, 2013-11-16 at 19:28 -0500, Paul Smith wrote:
> On Fri, 2013-11-15 at 18:00 -0500, Paul Smith wrote:
> > By this I mean, basically, multiple architectures (Linux, Solaris,
> > MacOSX, even Windows) sharing the same $prefix/lib/python2.7 directory.
> > The large majority of the contents there are completely portable across
> > architectures (aren't they?) so why should I have to duplicate many
> > megabytes worth of files?
> 
> OK, after some investigation and reading the code in Modules/getpath.c
> to determine exactly how sys.prefix and sys.exec_prefix are computed (it
> would be nice if this algorithm was documented somewhere... maybe it is
> but I couldn't find it) I have a solution for this that appears to be
> working fairly well.

Ouch.  I spoke a bit too soon.

The standard Python installation and interpreter works fine with the
"split --prefix and --exec-prefix" configuration, even with relocation
of the installation directory.  However, that configuration doesn't work
for embedded Python (for example, if you embed the Python interpreter in
GDB by linking libpython2.7.a) if you relocate it.

In that configuration when the interpreter looks for the lib/python
directory at runtime it appears to use only the prefix path Python was
originally compiled with (I'm using strace on Linux to see what paths
are being probed at startup).  It doesn't use the "current installation
path" via argv[0], which means it's not relocatable at all.

I can, of course, set PYTHONHOME to point to the right place.

Unfortunately, if you set PYTHONHOME then it's used for both $PREFIX and
$EXECPREFIX without any path probing whatsoever, so PYTHONHOME is
unusable with an installation where you've used different values for
--prefix and --exec-prefix during configure.

We'd need a new environment variable, like PYTHONEXECHOME or something,
which would be tested first when looking for the exec_path (only).  If
that didn't exist, it could try PYTHONHOME as before.

I'm willing to do this and file a bug with a patch if there's any
interest in pursuing it further.  Or should this be discussed on
python-dev?




More information about the Python-list mailing list