The way I have seen that resolved - in many locations, is to have the 
option to specify a specific version, e.g., libFOO.so.1 and then as long 
as that version remains available, perhaps as read-only for running with 
existing programs,they continue to work even when libFOO.so.2. However, 
for some who believes, or expects, to be able to deal with potential ABI 
changes - they can specify simply libFOO.so and let the loader decide 
(what I see is that libFOO.so is a symbolic link to, or a copy of the 
latest version.)

So, I agree wholeheartedly, if a versioned number is requested, that, or 
nothing, should be returned. However, if it is generic - try to find a 
generic named library (and get the link or copy), and when that is not 
available either, take the latest versioned number.

It has been over two months, and I may have read it wrong - but that 
appears to be what the current "ldconfig -p" solution implements. (in 
ctypes, not uuid, so perhaps this is not the correct place to be 
responding. If so, my apologies).

On 08-May-16 05:24, Martin Panter wrote:
> Martin Panter added the comment:
>
> The versioning problem with libFOO.so.N already occurs with compiled programs. A C program compiled against libuuid.so.1 will fail to load if you only have libuuid.so.2. On the other hand, a Python program using find_library() will find either version. My point about robustness is that if a version 2 is invented, it might have different semantics or function signatures, and Python would then be assuming the wrong semantics.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue11063>
> _______________________________________