On Apr 4, 2006, at 1:29 AM, Martin v. Löwis wrote:
> Zachary Pincus wrote:
>> Specifically, this patch would change a core python code path.
>
> Why do you think so? I believe Python always passes absolute paths
> to dlopen, so any path resolution dlopen might do should be
> irrelevant.
> *If* you can get dlopen to look at directories outside sys.path,
> that would be a serious problem. You can use ktrace to find out
> what places it looks at.
Sorry, I meant path in a more metaphoric sense; e.g. on OS X /
Darwin, Python used to go through the code in dynload_next.c every
time it loaded an extension, now under the proposed patch it goes
through dynload_shlib.c.
>
>> But it would be good to have a specific benchmark to know nothing
>> will break. I personally sort of feel that if dlopen() works once or
>> twice, it will probably always work, but there are those who probably
>> understand better the failure modes of opening shared libs as python
>> extensions, and could suggest some good things to test.
>
> Running the test suite should already exercise this code a lot.
> You should run the test suite both in "working copy" mode, and
> in "make install" mode; if you know how to produce a Mac installer,
> testing it in such an installer ("framework mode"?) could also
> be done.
I'll do this, thanks.
Zach
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4