Martin Panter added the comment:
I also found Issue 18502 essentially about the same incompatibility between
CDLL() and find_library().
The problem I see with using find_library() to blindly load a library is that
you could be loading an incompatible version (wrong soname). That is why I
asked Pau why they couldn’t give the proper library name to CDLL().
I noticed that Python’s own “uuid” module calls CDLL(find_library("uuid")); see
<https://hg.python.org/cpython/annotate/v3.5.1/Lib/uuid.py#l459>. On my Linux
computer, the full library name is libuuid.so.1, and according to online man
pages, this is also the case on Free BSD. So I wonder if the “uuid” module
should call CDLL("libuuid.so.1") directly. If somebody invented a new
incompatible version libuuid.so.2, Python’s uuid module might crash, or become
subtly broken, but programs that linked directly to libuuid.so.1 would continue
to work.
Does anyone have any valid use cases where they want to use a shared library on
LD_LIBRARY_PATH or similar, but cannot use CDLL() or LoadLibrary() directly? If
people really want a way to load a library given its compile-time name, maybe
changing find_library() is a valid way forward. But to me the use case does not
seem robust or worth blessing in Python’s standard library.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
