aixtools added the comment:
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 <rep...@bugs.python.org>
> <http://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
