Author aixtools@gmail.com
Recipients Arfrever, Keith.Dart, Michael.Felt, aixtools@gmail.com, christian.heimes, eric.araujo, hynek, kdart, knny-myer, martin.panter, nailor, nvetoshkin, orsenthil, pitrou, r.david.murray, serhiy.storchaka
Date 2016-05-13.06:20:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <5735724A.7060709@gmail.com>
In-reply-to <1462677894.34.0.849473945862.issue11063@psf.upfronthosting.co.za>
Content
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>
> _______________________________________
History
Date User Action Args
2016-05-13 06:20:47aixtools@gmail.comsetrecipients: + aixtools@gmail.com, orsenthil, kdart, pitrou, christian.heimes, eric.araujo, Arfrever, r.david.murray, nvetoshkin, knny-myer, nailor, Keith.Dart, hynek, martin.panter, serhiy.storchaka, Michael.Felt
2016-05-13 06:20:46aixtools@gmail.comlinkissue11063 messages
2016-05-13 06:20:46aixtools@gmail.comcreate