Michael Felt added the comment: On 27-Aug-16 09:11, Martin Panter wrote: > Martin Panter added the comment: > > The documentation is in RST format in the Doc/ directory. For basic stuff, > you can just copy the syntax from existing text, or see e.g. > <https://docs.python.org/devguide/documenting.html#restructuredtext-primer> > for more hints. For this change, I think we need to mention in > Doc/library/ctypes.rst: > > * the special AIX changes for find_library(); include “.. versionchanged::” > (or maybe versionadded? I’m not sure) notice > * the change for the CDLL constructor, also with versionchanged > > Perhaps also add an entry to Doc/whatsnew/3.6.rst. > > Patch 160823 does not addressed many of my previous comments. Please have a > closer look. I can make simple changes to simplify the code myself, but I > don’t really know what to do about the questionable regular expressions, for > instance. As far as regular expressions go, that will always be difficult for me aka questionable for you. Every language has it's nuances and I never seem to get them right.
> > Also, see <https://bugs.python.org/issue26439#msg268885>. What was wrong with > the cases supported by your original patches? As you clearly pointed out, there were no prior cases showing their need. I was taking an unbiased approach in that I knew no previous code well. I was just trying to make it work and was trying to think of cases were it could go wrong. In short, I was trying to solve issues that do not exist. People accept whatever libFOO.so points to as a symbolic link - and expect libSOO.so to be the name of the shared library that dlopen() is going to open somewhere. Once I understood the boundaries of find_library("foo") I limited myself to only resolve in the way the compile-time resolution is done. As such, find_library("c") is the equivalent of -lc and needs to resolve to libc.a(shr.o) - period (32-bit) or libc.a(shr_64.o) (64-bit). The linker is not looking for a particular member name: it only uses -lFOO to find libFOO.a, and it it exists it looks for a symbol. The member name that contains the symbol is what it stores in the executable (displayed via dump -H). So, getting back to this patch and packaging conventions. Basically, libtool has standardised how members are named, i.e., versioning. In most cases with OSS packages the only member-name that gets stored is the same name that libFOO.so would be a symbolic link to. Again, the compiler-linker only needs the name of the archive. The member name within the archive is irrelevant - from a compiler/linker perspective. My goal for find_library() is to find the most likely name based on some legacy "rules" from the way IBM packaged libraries starting over 20 years ago (aka AIX 4 standards) that are alive today to support binary compatibility - as much as possible. Mainly, that is relevant for libraries/archives such as libc.a. For new libraries, especially OSS packages built using the GNU autotools (and finishing with libtool) there are other conventions. Finally, we had different goals - my focus was on writing something that matches other platforms python2 behavior, not on writing a new syntax specific for Python3.6 and AIX. If I were to do be writing a new syntax I would prefer that it also work for other platforms. Something different for only one platform feels wrong - imho. In closing: a) regular expressions and me is always a headache for someone. please accept my apologies if I have given you a headache. b) I had assumed abilities for find_library() (from studying the output of ldconfig and trying to follow the regular expressions in the current code) that are not used. To assume makes an ass of u and me - especially me. c) I also apologize for not meeting your expectations. I cut code, rather than defend it, as you were correct that is was not based on meeting the needs of general aka current practice. I am not trying to redesign find_library(). My hope is that most python code would work asis - if they follow conventions aka general practice (not equivalent to best practice as best depends (in part) on your goal). > > ---------- > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue26439> > _______________________________________ ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26439> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
