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 <report@bugs.python.org>
> <https://bugs.python.org/issue26439>
> _______________________________________