Mathias Fröhlich added the comment:
Hey,
Shakeeb Alireza is right, the original problem was an application that links
and embeds against libpython*{so,dll,dynlib} and should more easily find
components like /*/lib*/python*.*/site.py and most probably now it needs to
find getpath.py as well
Mathias Fröhlich added the comment:
Ok, so far.
But what shall I do now?
It would be nice that python is a bit smarter in finding its increasing
important module files when being embedded into an application.
Anybody out there who wants to look at that contribution?
best
Mathias
Mathias Fröhlich added the comment:
Yes.
msg191944 from Nick Coghlan, made me think that with all the initialization
rework that appeared to be underway you want to incorporate that presented idea
of basing the default onto the location of the libpython.so or the
pythonX.X.dll instead
Mathias Fröhlich added the comment:
Hi,
Nice to see some progress.
Still, I checked todays https://github.com/python/cpython.git master and 3.8
branch (is that the current cpython development code?). Neither of them contain
a call to dladdr beside the macos code path mentioned in msg191994
Mathias Fröhlich added the comment:
Hi Ronald, Eric, Nick,
Looking up the symbol name of the current function should work also.
And I am free to rename these functions to whatever you like.
Attached is version 2 of the patch with the suggested changes.
The windows implementation is still
Mathias Fröhlich added the comment:
Hi Eric,
Thanks for looking at that ticket so fast!
Reassigning this to 3.4 is great.
In general, yes I can already do what I need more or less. This is the reason
why I can be fine with about every python version.
The point I bring up this change that I
New submission from Mathias Fröhlich:
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
