[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Charles Coulombe added the comment: Any update on this issue? This would be helpful to HPC systems that don't have libraries installed in standard place, and to standardize find_library as well! -- nosy: +Charles Coulombe versions: -Python 3.6

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Martin Panter added the comment: I reverted the change until we can come up with something more consistent. -- stage: commit review -> needs patch ___ Python tracker

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Roundup Robot added the comment: New changeset 811ec2860dc4 by Martin Panter in branch 'default': Issue #21042: Revert Linux find_library() to return just filename https://hg.python.org/cpython/rev/811ec2860dc4 -- ___ Python tracker

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Martin Panter added the comment: It looks like the ldconfig parsing isn’t working for some ABIs. See the following buildbot failures: * Cortex A15 armv7l: http://buildbot.python.org/all/builders/ARMv7%20Ubuntu%203.x/builds/3721/steps/test/logs/stdio * ppc64le POWER8:

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Roundup Robot added the comment: New changeset 3092cf163eb4 by Martin Panter in branch 'default': Issue #21042: Return full path in ctypes.util.find_library() on Linux https://hg.python.org/cpython/rev/3092cf163eb4 -- nosy: +python-dev ___ Python

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Martin Panter added the comment: No I think this is ready Tamás. I have been away, but it is on my list of things to catch up on. I won’t add any What’s New entry. -- stage: patch review -> commit review ___ Python tracker

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Tamás Bence Gedai added the comment: Is there anything else that I can do for this issue? -- ___ Python tracker ___

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Berker Peksag added the comment: I don't think we need an entry in whatsnew/3.6.rst for this (we already have documented the change in a versionchanged directive and a Misc/NEWS item) -- nosy: +berker.peksag ___ Python tracker

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Martin Panter added the comment: Thanks, this looks pretty good to me. I just need to remember to write a What’s New entry. -- ___ Python tracker ___

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Tamás Bence Gedai added the comment: Updated the patch to remove the code duplication, now it stores the values that are calculated in the setUpClass method. It was a good and simple idea, I should have come up with it... :) I'm pretty sure I got the errors during configuration because of the

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Martin Panter added the comment: I left a suggestion about the duplication in the code review. I set CC with “configure” like you said. I also had to run “make clean” to get rid of the old 64-bit stuff. But it might depend on the GCC that you have installed. On Arch Linux, I have

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Tamás Bence Gedai added the comment: I've added a new method to Test_OpenGL_libs as you suggested. I check whether find_library returns an absolute path. Note that I didn't distinguish different systems, as according to the docs, only Linux systems return the file name, other systems return

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Martin Panter added the comment: Tamás, it might be a good idea for you to sign a contributor agreement . I compiled Python in 32-bit mode and tried your v2 patch out, which found the wrong library as I predicted. Then I tried your new regex

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Tamás Bence Gedai added the comment: What do you think about this regex? '(lib%s\.[^\s]+\s\(%s(?:\)|,\s.*\))\s=>\s.*)' % (re.escape(name), abi_type)) It works on 64 bit, just like before, but I could not test it on 32 bit. I'll add tests soon. I looked for documentation on ldconfig, but

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Martin Panter added the comment: I think the new regular expression will still find the wrong library in my libm example above. In 32-bit mode, it will be only looking to match \(libc6.*\). Since my example has the 64-bit line first, that one will match first. (I haven’t actually tested this,

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Tamás Bence Gedai added the comment: I fixed the ABI matching, it was a stupid mistake, thanks for pointing it out :) I think now it works as expected. I really don't find a place for testing. Maybe a new test file could be added, but I think the testing code for find_library wouldn't be more

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Martin Panter added the comment: The ABI matching looks wrong to me. If I am looking for a 32-bit library, won’t it incorrectly catch the wrong path in the following “ldconfig -p” output: '\tlibm.so.6 (libc6,x86-64, OS ABI: Linux 2.6.32) => /usr/lib/libm.so.6\n' '\tlibm.so.6 (libc6, OS ABI:

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Tamás Bence Gedai added the comment: Added a new patch, as Martin pointed out, I put back the ABI matching. The regex looks quite ugly, because it has to match \n\t. To be exact, it has to match something like this: "/lib/x86_64-linux-gnu/libc.so.6\n\tlibbz2.so.1.0 (libc6,x86-64)". I updated

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Gedai Tamás Bence added the comment: Added a small patch that solves this issue on Ubuntu 15.10. Produces output like: /lib/x86_64-linux-gnu/libm.so.6 /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libbz2.so.1.0 I'd be glad to add some test cases if someone can give me some tips on how

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Martin Panter added the comment: IMO this should be treated as a new feature for the next release. But consistently returning the path sounds good to me if there is no good reason not to. Left a question on the review. I think you also need to update the documentation, and since this is

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

New submission from Hernan Grecco: In Windows and OSX, `find_library` returns the full pathname of the library file. But on Linux, it returns just the filename. Is there a reason for this difference? For consistency, it would be better to return the full pathname in all cases. It is easy to