aixtools added the comment: 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 <rep...@bugs.python.org> > <http://bugs.python.org/issue11063> > _______________________________________ ---------- nosy: +aixto...@gmail.com _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11063> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
