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 Michael.Felt
Recipients Brian.Larsen, Daniel.Blanchard, Michael.Felt, Pau Tallada, amaury.forgeotdarc, belopolsky, jniehof, lukasz.langa, martin.panter, meador.inge, vinay.sajip, yaroslavvb
Date 2016-07-29.13:28:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1469798917.41.0.807731153932.issue9998@psf.upfronthosting.co.za>
In-reply-to
Content
Vinay - I am in favor, but if the root cause of the holdup is unclear documentation then let's address the root cause.

Stronger, I am in agreement. The first patch I submitted for AIX included using LIBPATH (and could have added LD_LIBRARY_PATH) - but that was rejected.

> 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.

* Again, basically I agree with the principles. I do not have the resources for all linux platforms, Solaris, BSD, Windows, etc..
* As far as "other platforms" and dlopen() behavior - from the man pages I have referenced I see more similarity than difference.
* behaviour of find_library is system-dependent - exactly - but unfortunately, for now AIX is whatever is in the else: box. That it works at all is a statement of the flexibility of AIX - and the sweat and tears of AIX admins to get the pieces to fit.

> 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.

Good points. However, while it cannot be guaranteed - upfront - (although I would say that I could make them mimic each other on AIX given the leeway, better directive) - it can be stated as an objective for "posix".
:) Windows is windows - maybe someone who knows windows well enough could make something very close.

> The purpose of find_library as currently documented seems adequately described, and the documentation update in my latest patch clarifies things further.

Obviously, here is where we disagree. If it was 'adequately' described you could have used the documentation as a justification years ago. Your change touches on it, but still leaves a great deal to discuss - and especially - convince those who may actually commit.

> 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.

As you mentioned earlier - the implementations are system-dependent - so yes, we could argue for find_library search behavior that emulates dlopen() (better perhaps "LoadLibrary()") - but not define any particular behavior - precisely because it may be different on different platforms. Again, the objective is to replicate that platform's LoadLibrary search behavior - whatever that may be.

Once we have established what is needed/desired as a goal, over time implementations will catch up. Linux will be leading the way because you have, presumably, already implemented it.

Michael
History
Date User Action Args
2016-07-29 13:28:37Michael.Feltsetrecipients: + Michael.Felt, vinay.sajip, amaury.forgeotdarc, belopolsky, meador.inge, lukasz.langa, jniehof, Brian.Larsen, yaroslavvb, martin.panter, Daniel.Blanchard, Pau Tallada
2016-07-29 13:28:37Michael.Feltsetmessageid: <1469798917.41.0.807731153932.issue9998@psf.upfronthosting.co.za>
2016-07-29 13:28:37Michael.Feltlinkissue9998 messages
2016-07-29 13:28:36Michael.Feltcreate