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 vinay.sajip
Recipients Brian.Larsen, Daniel.Blanchard, Michael.Felt, Pau Tallada, amaury.forgeotdarc, belopolsky, jniehof, lukasz.langa, martin.panter, vinay.sajip, yaroslavvb
Date 2016-07-28.21:34:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1469741699.06.0.313980620533.issue9998@psf.upfronthosting.co.za>
In-reply-to
Content
In my view, the best should not be the enemy of the good, and pragmatism beats purity. I don't have the resources to test this functionality on all platforms - just Windows and Linux - and am not familiar with other platforms like AIX, Solaris or the BSDs. The documentation makes clear that the behaviour of find_library is system-dependent and makes no promises of a particular level of consistency, either with dlopen() or across platforms. Nor can we guarantee in the documentation that find_library() will exactly emulate dlopen(), since that may not hold on all platforms - and in fact, since Windows is in the mix, there is little point in trying to tie find_library() behaviour to that of dlopen() directly.

My documentation update makes clear that for Linux only, LD_LIBRARY_PATH will be searched if the existing mechanisms give no joy.

This request has been around since 2010, and in my view implementing this long-overdue patch will improve matters for Linux users and IIUC meet the goals of the issue creator and other commenters who concurred with his sentiment. This does not preclude improving the functionality on other platforms later, but I think we should implement this patch unless someone can point out that it makes things worse in some way. If anyone can improve it, that is also to be welcomed, of course.

> As such, I would oppose a patch that only addresses the specifics of one platform.

Why would improving behaviour on one platform, without any API changes or needing additional work by users, be worthy of opposition?

> What is needed is a "design" clarification of the purpose of find_library.
> If we can agree on that "implementation" can follow.

The purpose of find_library as currently documented seems adequately described, and the documentation update in my latest patch clarifies things further. IMO this is an area where the underlying platform features which find_library() relies on, as well as the run-time dynamic linking facilities available, are quite different across platforms. 

I'm not sure the agreement you seek will come any time soon, as it has not come in the last five years; it doesn't seem possible to aim for e.g. exact behaviour of dlopen(), because (a) it's not the same on Windows and (b) potentially varies too widely across POSIX platforms. Can you propose some change to the find_library() contract which you can assure will be implementable across all platforms? Certainly, fidelity with dlopen() isn't it.
 

> IMHO - trying to get a patch in for the convenience of one platform is not an architectural enhancement.

We're not trying for an architectural enhancement here, AFAIK.

I would welcome some input from others!
History
Date User Action Args
2016-07-28 21:34:59vinay.sajipsetrecipients: + vinay.sajip, amaury.forgeotdarc, belopolsky, lukasz.langa, jniehof, Brian.Larsen, yaroslavvb, martin.panter, Daniel.Blanchard, Michael.Felt, Pau Tallada
2016-07-28 21:34:59vinay.sajipsetmessageid: <1469741699.06.0.313980620533.issue9998@psf.upfronthosting.co.za>
2016-07-28 21:34:59vinay.sajiplinkissue9998 messages
2016-07-28 21:34:58vinay.sajipcreate