This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mathias
Recipients eric.snow, mathias, ncoghlan, ronaldoussoren, vstinner
Date 2019-09-26.06:31:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1569479475.76.0.373286063003.issue18309@roundup.psfhosted.org>
In-reply-to
Content
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 by Ronald Oussoren which does this already for a long time.
By the lack of dladdr, I conclude that the code idea of my request here is not solved.

May be to rephrase that. The basic idea behind that request was to make
pythons default way to setup the paths required to find the python modules based on the place where the python library resides instead of the python executable program. I do not mean the compile time prefix but the actual location of the shared object in the file system.
That would help to build applications that embed cpython, ship and unpack the whole application tree including the python modules to a custom location, while still preserving the subtree structure containing the python shared library and the python modules, not known at compile time. Note that this patch contained code to make that work from within python without custom code in the embedding application. Doing that on the embedding and calling application side was always possible and still is possible - but that was not the point.

best

Mathias
History
Date User Action Args
2019-09-26 06:31:15mathiassetrecipients: + mathias, ronaldoussoren, ncoghlan, vstinner, eric.snow
2019-09-26 06:31:15mathiassetmessageid: <1569479475.76.0.373286063003.issue18309@roundup.psfhosted.org>
2019-09-26 06:31:15mathiaslinkissue18309 messages
2019-09-26 06:31:15mathiascreate