Hi all,

I want to move python a bit closer to be relocatable.
One problem to solve is where python finds its modules.
The usual lookup mechanism is to compile in a configure time
determined prefix that is used as a last resort path if the
paths are not set otherwise during application/interpreter startup.
The most commonly known way to change the module path at startup time
are probably the environment variables PYTHONPATH and PYTHONHOME.
The python interpreter itself already tries to interpret argv[0] to get to this point, but it would be nice if an application embedded interpreter also finds its module path without providing this argv[0] directly to the python library. This should even work if being moved or being installed at a different path than the configure time prefix path.

The proposal is to add an additional attempt to find the python modules
just before we resort to the compiled in prefix by looking at the path
to the python27.{so,dll}. Relative to this shared object python library
file the python modules are searched in the usual way. If there are
no python modules found relative to the python library file, the very
last resort compiled in prefix is used as usual.

For architectures where we cannot determine the path of the shared
library file, nothing changes.

I have attached a patch that tries to implement this.
It should serve as a base for discussions.
This change is tested on linux and behaves like expected. The windows code for this is copied over from an other project where I have this actively running. But this python code variant is not even compile tested on windows.

thanks in advance

Mathias