On 28-May-16 04:04, Martin Panter wrote:
> Martin Panter added the comment:
>
> Strictly speaking, Python 2.7 never had special support for RTLD_MEMBER or find_library(). That is why I am unsure about many of these changes being done in 2.7. They seem more like new features than bug fixes. Especially once you start talking about a smart CDLL() that tests for a file and then falls back to RTLD_MEMBER.
Well, actually, within AIX I was intending to "just use" RTLD_MEMBER 
when "the string" ended in a ")" as that is the correct additional mode 
bit for an established interface dlopen(). I perhaps do not understand 
(certainly did not) the goal of CDLL(), better Lib/ctypes

As far as Python-2.7 is concerned - I would like to see it "in" because 
there is a lot of Python-2(.7) code out there that will not work without 
manageling AIX at a low level (i.e., current practice is to extract .so 
members from archives so dlopen() will be able to open them.
>
> Whether you represent an archive member as an (archive, member) tuple, or as an "archive(member)" string, or something else, it is still an extension of the API of CDLL(), and arguably also of find_library().
I would want to disagree. A string is a string, regardless of the 
characters in it. And, I have verified - if a file 
/usr/lib/libFOO.a(libFoo.so.X) exists dlopen() will open it when 
RTLD_MEMBER is not ORed into the mode.
> I think I have already tried to explain that on Linux, find_library("libm.so") is far from normal usage (although may be technically legal if there was a library called liblibm.so.so).
find_library("libm.so") is far from normal usage: again, my 
misunderstanding - I was reading as much as possible from various 
sources - and my head was spinning.
In util.py there was no "libFOO.so", only "FOO" and "libFOO" - so my 
find_library() tests are not correct. Agreed.

>
> Also, on Linux I wouldn’t recommend CDLL("libcrypt.so"), which relies on a file only intended for build time. On Debian, the glibc library <https://packages.debian.org/source/jessie/glibc> has separate packages for shared libraries (libc6) and development libraries (libc6-dev). It should be possible to run programs with libc6 installed, but without libc6-dev. Looking at the file lists for “i386” architecture, libc6-dev includes:
>
> /usr/lib/i386-linux-gnu/libcrypt.a
> /usr/lib/i386-linux-gnu/libcrypt.so
My expectation (misconception perhaps) is that Linux uses a .a archive 
for static linking, and .so shared-library for dynamic-loading. The AIX 
loader/linker looks first in .a archives for shared libraries (when 
static is not specified) and if no member is found (member name is not 
relevant for the search, only the symbol and the object size (32 or 64 
bit)). If not found in libFOO.a then a search for a specific file is 
done libFOO.so.

An assumption of mine is: if I specified (not usual on AIX, based on my 
experience) -lc.so.6 AIX would look for an archive named libc.so.6.a 
first. If found, would look for a member in that archive. If not found 
as a .a archive and/or not found as a file at all then it will look for 
a file libFOO.so.6

>
> It symbolically links to /lib/i386-linux-gnu/libcrypt.so.1, which is provided by libc6:
>
> /lib/i386-linux-gnu/libcrypt-2.19.so
> /lib/i386-linux-gnu/libcrypt.so.1
>
> So on Debian (and with Linux in general), CDLL("libcrypt.so") may work in some cases, but you should normally use CDLL("libcrypt.so.1") instead.
Agreed - CDLL("libFOO.so") is not preferred. But, should it be refused? 
Or, if it is accepted on Linux - and works when the (symbolic) file 
exists - must it be refused on AIX? If refusing it on AIX is what it 
takes to make the patch acceptable - then code it to refuse it is.
>
> Usually people just upload a new version of the original patch (original changes, plus new changes, in one file). I think it would be too confusing looking at differences between two patches.
So, just provide the new delta between "2.7.11(.0) and what I have, not 
the changes between patches. Coming up tomorrow.

In short, my head was spinning and I thought I saw problems that are not 
meant to exist, in particular find_library("libFOO.so") - that should be 
coded to reject I guess. I would still like to let something like 
"libc.so" be creative, as libc.so will never exist, by default, on AIX. 
My guess is that is a legacy thing from AIX4. (and I think the default 
name is shr.o when using the ld flag -G to create a shared object aka 
shared library)
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue26439>
> _______________________________________