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, vinay.sajip, yaroslavvb
Date 2016-07-28.20:25:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1469737509.62.0.112485830432.issue9998@psf.upfronthosting.co.za>
In-reply-to
Content
imho - it is not correct to only make a modification of this nature for a single platform.

To be realistic, if the "design" goal is to 'find' what dlopen() will find when given a argument without a pathname component - then gcc should not be used, and perhaps only your 'ld' based solution (which I have not read).

From linux man pages: both the justification to consider *PATH* for all platforms (i.e., LD_LIBRARY_PATH is a GNU/Linux construct, not the default for all platforms.)

"""
dlopen()

The function dlopen() loads the dynamic library file named by the null-terminated string filename and returns an opaque "handle" for the dynamic library. If filename is NULL, then the returned handle is for the main program. If filename contains a slash ("/"), then it is interpreted as a (relative or absolute) pathname. Otherwise, the dynamic linker searches for the library as follows (see ld.so(8) for further details):
o

(ELF only) If the executable file for the calling program contains a DT_RPATH tag, and does not contain a DT_RUNPATH tag, then the directories listed in the DT_RPATH tag are searched.

o

If, at the time that the program was started, the environment variable LD_LIBRARY_PATH was defined to contain a colon-separated list of directories, then these are searched. (As a security measure this variable is ignored for set-user-ID and set-group-ID programs.) 
""" end of excerpt

In short, this is more than just LD_LIBRARY_PATH. And my preference is that *PATH*, if predefined, should be taken into consideration by find_library. In other words, the purpose of find_library is to resolve platform naming conventions of shared libraries given a 'generic' argument, e.g., find_library("c") on Linux returns libc.so.6 while for AIX it (should return) libc.a(shr4.o).

As such, I would oppose a patch that only addresses the specifics of one platform. What is needed is a "design" clarification of the purpose of find_library. If we can agree on that "implementation" can follow. IMHO - trying to get a patch in for the convenience of one platform is not an architectural enhancement.

Again, I would like to see the documented behavior to be that find_library returns what dlopen() would open - when given an argument is the correct platform syntax. A patch for Linux does not - formally - guarantee that documented change.
History
Date User Action Args
2016-07-28 20:25:09Michael.Feltsetrecipients: + Michael.Felt, vinay.sajip, amaury.forgeotdarc, belopolsky, lukasz.langa, jniehof, Brian.Larsen, yaroslavvb, martin.panter, Daniel.Blanchard, Pau Tallada
2016-07-28 20:25:09Michael.Feltsetmessageid: <1469737509.62.0.112485830432.issue9998@psf.upfronthosting.co.za>
2016-07-28 20:25:09Michael.Feltlinkissue9998 messages
2016-07-28 20:25:09Michael.Feltcreate