[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Zachary Ware]

Zachary Ware  added the comment:

Thanks Michael, finally getting it closed :)

--
nosy: +zach.ware
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt  added the comment:

as this is not (likely) to be backported to Python2 (by python, fyi: I do 
include full ctypes-load_library() support in my "independent" packaging)

and it is "resolved" for Python3-3.7 issue26439

this issue may, imho, be closed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Change by Michael Felt :


--
pull_requests: +5012
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt  added the comment:

On 24/02/2017 09:44, Michael Haubenwallner wrote:
> Michael Haubenwallner added the comment:
>
> Let's switch to github-based patches to discuss about:
> https://github.com/python/cpython/compare/2.7...haubi:issue27435/2.7
>
> For the library search path I prefer to use loadquery(L_GETLIBPATH), 
> available via new _ctypes_aix module now, but also used with L_GETINFO in 
> Python/dynload_aix.c already.

Back again - I could not find the _ctypes_aix you mentioned. github was 
new, and I had no time then. And what I saw in dynload_aix.c I did not 
understand. I was trying to emulate what I saw in the existing 
Lib/ctypes (i.e., resolve it in python code) rather than write code in C.

Clearly, you understand that path - I (still) do not. Obviously - making 
a library call is more efficient than making multiple subprocess calls.

I may be far enough along with git that I might be able to figure out 
how to "fetch" what you have on github as haubi:issue27435/2.7.

This may also be better, i.e., more efficient, ultimately, than what was 
merged via https://github.com/python/cpython/pull/4507

Now that I have found your work - thank you for all the time you put 
into this last year!

Michael

>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[David Edelsohn]

Change by David Edelsohn :


--
nosy: +David.Edelsohn

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt added the comment:

First, my apology that I have not responded earlier. I had other things 
to work on (real life things), customers that had interest in a fix for 
find_library() have indicated no longer have interest, and also my 
personal issue - becoming disillusioned with the lack of progress in the 
discussion.

Clearly, the detail of your comments proves me wrong on that final 
point. I will be more attentive.

Jumping to your last comment:

> Uhm, ultimative solution feels complex already, while still some things to 
> decide...

So, rather than try for perfection in one go - set some priorities.

IMHO (emphasis on the H) - having find_library return something useful, 
even if not right 100% of the time - is better than wrong 100% of the 
time. - this concerns find_library().

Your "find" of the routine "loadquery()" may be a big improvement over 
what I found first. FYI - while you show links to AIX 7.2 documentation 
I am, as a 'packager' still trying, for the time being, to package on 
AIX 5.3. I know AIX 5.3 is no longer supported, but as long as something 
such as RBAC intelligence is not needed I prefer to package only once - 
and let AIX binary compatibility upwards do it's thing. Back to the H 
from above: loadquery() is an enhancement - and in previous discussions 
about my patch, such enhancements were frowned upon (i.e., it seemed 
that anything that would consider  or include LD_LIBRARY_PATH or LIBPATH 
would not be considered - so even something that would examine the 
environment (i.e., an exported LD_LIBRARY_PATH or LIBPATH) was not 
acceptable. However, I concur loadquery() using *L_GETLIBPATH*can be 
expected to be more efficient (and easier to read?) that my earlier 
attempts to get this info using "dump -H".

More comments (a few) below.

On 20/02/2017 14:37, Michael Haubenwallner wrote:
> Michael Haubenwallner added the comment:
>
> On 02/03/2017 09:52 PM, Michael Felt wrote:
>>> Anyway:
>>> Unfortunately, there is no concept of embedding something like ELF's 
>>> DT_SONAME tag into the Shared Object.
>>> The very (PATH,BASE,MEMBER) value as (specified to and) discovered by the 
>>> linker is recorded into the just-linked executable (or Shared Object).
>>> This implies that the runtime loader does search for the very same filename 
>>> (and member eventually) as the linker (at linktime).
>> I assume this is why there are many systems besides AIX that do not
>> support/use DT_SONAME.
> Except for Windows, I'm not sure which "many systems besides AIX" you're 
> talking here about, that "do not use/support DT_SONAME".
Clearly, my assumption is wrong. I "grew up" on BSD Unix, not System V, 
and AIX seems (imho) favor BSD in some aspects. I assume (emphasis 
assume!) that soname is not part of the POSIX standard (at least not as 
early as 2005 - standards change).
>> At least I see many references to "Shared
>> Objects" libFOO.so.X.Y.Z, libFOO.so.X.Y, libFOO.so.X and libFOO.so (with
>> the latter three being symbolic links to the first).
> When a system happens to find these symlinks useful, then it actually _does_ 
> support embedding DT_SONAME (or something similar) into its binary file 
> format.
What I have seen on AIX - packaging by others, and from memory what 
libtool is doing, is the following: the file: libfoo.so.X.Y.Z gets 
created, the following symbolic links are created - each pointing at 
libfoo.so.X.Y.Z: libfoo.so.X.Y, libfoo.so.X and libfoo.so. I also see 
the same "logic" in IBM provided archives. I use libssl.a as my guide 
(for 'versioning'), but most of my 'issues' has been with supporting 
backwards compatibility with libintl.a - execpt here they are not 
symbolic links. The same "file" is added to the archive, but with a 
different name - so if a "soname extension" was used (better, found 
during linking), it is used. The order in the archive is important. If 
the generic name is first, then that is the name that will be used 
during linking (and remembered for execution).

root@x064:[/usr/lib]lslpp -L | grep openssl.base
   openssl.base1.0.2.1000C FOpen Secure Socket Layer
root@x064:[/usr/lib]ar -Xany -tv libssl.a
rwxr-xr-x 537912/767508 726474 Oct 18 11:38 2016 libssl.so
rwxr-xr-x 537912/767508 726474 Oct 18 11:38 2016 libssl.so.1.0.0
rwxr-xr-x 537912/767508 510610 Oct 18 11:39 2016 libssl.so.0.9.8
rwxr-xr-x 537912/767508 823217 Oct 18 11:39 2016 libssl64.so
rwxr-xr-x 537912/767508 823217 Oct 18 11:39 2016 libssl64.so.1.0.0
rwxr-xr-x 537912/767508 577122 Oct 18 11:54 2016 libssl64.so.0.9.8

root@x064:[/usr/lib]lslpp -L aixtools.gnu.gettext.rte
   Fileset  Level  State  Type  Description 
(Uninstaller)

   aixtools.gnu.gettext.rte  0.19.8.1C Fbuilt 21-Aug-2016 
1821 UTC

root@x064:[/usr/lib]ar -Xany tv libintl.a
rwxr-xr-x 0/0  87530 Aug 21 16:45 2016 libintl.so.8
rwxr-xr-x 0/0  79727 Aug 21 18:17 

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Haubenwallner]

Michael Haubenwallner added the comment:

Let's switch to github-based patches to discuss about:
https://github.com/python/cpython/compare/2.7...haubi:issue27435/2.7

For the library search path I prefer to use loadquery(L_GETLIBPATH), available 
via new _ctypes_aix module now, but also used with L_GETINFO in 
Python/dynload_aix.c already.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Haubenwallner]

Michael Haubenwallner added the comment:

On 02/03/2017 09:52 PM, Michael Felt wrote:
>> Anyway:
>> Unfortunately, there is no concept of embedding something like ELF's 
>> DT_SONAME tag into the Shared Object.
>> The very (PATH,BASE,MEMBER) value as (specified to and) discovered by the 
>> linker is recorded into the just-linked executable (or Shared Object).
>> This implies that the runtime loader does search for the very same filename 
>> (and member eventually) as the linker (at linktime).
> 
> I assume this is why there are many systems besides AIX that do not 
> support/use DT_SONAME.

Except for Windows, I'm not sure which "many systems besides AIX" you're 
talking here about, that "do not use/support DT_SONAME".

> At least I see many references to "Shared 
> Objects" libFOO.so.X.Y.Z, libFOO.so.X.Y, libFOO.so.X and libFOO.so (with 
> the latter three being symbolic links to the first).

When a system happens to find these symlinks useful, then it actually _does_ 
support embedding DT_SONAME (or something similar) into its binary file format.

> Another issue is support for what I believe MacOS calls "fat" objects - 
> that support both 32-bit and 64-bit applications - rather than /XXX/lib 
> for 32-bit objects and /XXX/lib/lib64 or /XXX/lib64 for 64-bit objects.

Yes, the AIX Archive Libraries supporting different bitwidths for members is 
quite similar to MacOS fat objects.
However - although related, the creation of "fat" AIX archives is a different 
topic.
But yes, Python ctypes.find_library+dlopen should know how to deal with them.

> b) One of the difficulties I faced is trying to guess what version -lFOO 
> should find when there is more than one version available.

Exactly. There is an idea below (the symbol->member map).

>> But still, how to get ctypes.find_library() working - ideally for each 
>> variant, is another story. Right now it does not work for any variant,
> Do you mean all systems, or specific to AIX - I am assuming you mean AIX.

Yes - find_library currently does not work for any variant on *AIX*.

>> but I guess that search algorithm should follow how the linker discovers the 
>> (PATH,BASE,MEMBER) values to

> I am not a tool builder. My comments are based on observations and 
> experience from when I was a developer 25+ years ago. The AIX linker is 
> not interested in the member name - it seems to go through the 
> PATH/libBASE.a looking for the first object it can find to resolve a 
> symbol. The name of the object it finds becomes the MEMBER it records in 
> it's internal table of where to look later when the application runs.

Exactly.

>>   write into just-linked executables, combined with how the runtime loader 
>> finds the Shared Object to actually load.

> I worked on a patch - to do all that - taking into consideration the way 
> libtool names .so files/members and then looking into/at "legacy" aka 
> IBM dev ways they did things before the libtool model was so prominent.
> 
> My algorithm - attempts to solve the (PATH, BASE, MEMBER) problem as 
> "dynamically" as possible. PATH and BASE are fairly straight forward - 
> but MEMBER is clearly more complex.
> 
> PATH: start by looking at the python executable -

As far as I can tell, any executable can actually link against the Python 
interpreter.

> and looking at it's  "blibpath" -

There also is the loadquery() subroutine in AIX, see 
https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.basetrf1/loadquery.htm

loadquery(L_GETLIBPATH) "Returns the library path that was used at process exec 
time.",
which includes both the environment variable LIBPATH (or LD_LIBRARY_PATH if 
LIBPATH is unset) and the executable's "blibpath" value.

> and using that as the default colon separated list of PATHs

Question is if we do want to consider _current_ values of environment variable 
LIBPATH (or LD_LIBRARY_PATH) in addition to the "library path at process exec 
time"?

> to search for BASE.a archive. Once a BASE.a file is found it is examined 
> for a MEMBER. If all PATH/BASE.a do not find a potential MEMBER then the 
> PATHs are examined again for PATH/BASE.so.

Erm, nope, the AIX linker has a different algorithm (for -lNAME):
Iterating over the "library path", the first path entry containing any matching 
filename (either libNAME.a or libNAME.so) will be used, and no further library 
path iteration is performed.
This one found PATH/filename does have to provide the requested symbol in one 
way or another.

> When a .so file is found that 
> is returned - versioning must be accomplished via a symbolic link to a 
> versioned library.

The linker does not perform such a check, nor does it feel necessary for 
ctypes.find_library+dlopen as long as it does search similar to the linker.

> The program "dump -H" provides this information for both executables and 
> archive (aka BASE) members.

Eventually we might want to avoid spawning the 'dump' program, but implement 
reading the XCOFF Object File Format within 

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt added the comment:

On 31/01/2017 20:22, Michael Haubenwallner wrote:
> Michael Haubenwallner added the comment:
>
> Feels like it is up to me to shed some light on various topics here:
Many thanks!
>
> AIX defines (static) "Object" files and "Shared Object" files. Both can (but 
> do not need to) be members of an "Archive Library".
>
> When talking about (dynamically loading) a "shared library" on non-AIX 
> systems, the correct wording for AIX is (dynamically loading) a "Shared 
> Object" - independent of whether it is a standalone file or an archive member.
>
> As you already agreed on, ctypes.util.find_library() indeed should return the 
> location of the Shared Object - as either "/path/to/file" or 
> "/path/to/file(member)". And ctypes.CDLL() should add the RTLD_MEMBER flag to 
> _ctypes.dlopen() if there is the "(member)" part.
>
> However, that does not necessarily mean the RTLD_MEMBER value needs to be 
> available through the ctypes API. Instead, RTLD_MEMBER feels more appropriate 
> for the _ctypes API - and on AIX only.
>
> Anyway:
> Unfortunately, there is no concept of embedding something like ELF's 
> DT_SONAME tag into the Shared Object. The very (PATH,BASE,MEMBER) value as 
> (specified to and) discovered by the linker is recorded into the just-linked 
> executable (or Shared Object). This implies that the runtime loader does 
> search for the very same filename (and member eventually) as the linker (at 
> linktime).
I assume this is why there are many systems besides AIX that do not 
support/use DT_SONAME. At least I see many references to "Shared 
Objects" libFOO.so.X.Y.Z, libFOO.so.X.Y, libFOO.so.X and libFOO.so (with 
the latter three being symbolic links to the first).
>
> However, to still get some kind of shared library versioning, multiple 
> versions of one Shared Object are put into one single Archive Library, where 
> the "old" versions get the LOADONLY flag set (via 'strip -e') - so 
> executables linked against an old version still can load their "old" Shared 
> Object, while the linker discovers the "current" version only.
>
> But this "single-filename" based shared library versioning is a huge burden 
> for packages managers - either human or software, even when they maintain 
> their packages in a private prefix (like /opt/freeware, /usr/local and 
> similar). Neither can they put their "current" Shared Object's version into 
> the single (system's) Archive Library, nor can they mark existing Shared 
> Objects as LOADONLY.
> On the other hand, they also do not want to pull all the system versions into 
> their own Archive Library.
Another issue is support for what I believe MacOS calls "fat" objects - 
that support both 32-bit and 64-bit applications - rather than /XXX/lib 
for 32-bit objects and /XXX/lib/lib64 or /XXX/lib64 for 64-bit objects.
>
> So for package managers it is crucial to have "multi-filename" based shared 
> library versioning instead.
>
> But there is help:
> AIX also provides (plain text) "Import Files": They contain a list of symbols 
> for the linker, and a (PATH,BASE,MEMBER) tuple naming the Shared Object that 
> provides these symbols at runtime.
a) Yes to above
b) One of the difficulties I faced is trying to guess what version -lFOO 
should find when there is more than one version available. Applications 
that are already linked do not look for a latest version - they know the 
member name that the linker found initially. ctypes.utils.find_library() 
does not provide a way to say which version should be found. Each 
implementation has it's way to find a version (e.g., a search of 
ldconfig -p output for a best guess)
> So yes, Import Files can be used for "multi-filename" based shared library 
> versioning.
>
> Thus, libtool now offers the "--with-aix-soname=svr4" configure flag, where 
> "libNAME.so.X" really is created as an Archive Library, containing the Shared 
> Object "shr.o" with the LOADONLY flag set, and the Import File "shr.imp" 
> referring to "libNAME.so.X(shr.o)" for runtime. Combined with the symlink 
> "libNAME.so", for the "-lNAME" argument the linker discovers the Import File 
> "libNAME.so(shr.imp)" now, while recording "libNAME.so.X(shr.o)" into the 
> executable for the runtime loader.
> Note that for 64bit the Shared Object and Import File is named "shr_64.o" and 
> "shr_64.imp", respectively.
>
> While libtool's "--with-aix-soname=svr4" variant creates "libNAME.a" from 
> static Objects only, both libtool's "--with-aix-soname=aix" and 
> "--with-aix-soname=both" - for backwards compatibility - create "libNAME.a" 
> for traditional "single-filename" based versioning: Without any static Object 
> - as even Shared Objects can be linked statically(!). But to statically link 
> the Shared Object (as an archive member), neither the LOADONLY flag must be 
> set, nor an Import File must be found (as Import Files cannot serve for 
> static linking).
>
> And "--with-aix-soname=aix", libtool still creates standalone 
> 

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Haubenwallner]

Michael Haubenwallner added the comment:

Feels like it is up to me to shed some light on various topics here:

AIX defines (static) "Object" files and "Shared Object" files. Both can (but do 
not need to) be members of an "Archive Library".

When talking about (dynamically loading) a "shared library" on non-AIX systems, 
the correct wording for AIX is (dynamically loading) a "Shared Object" - 
independent of whether it is a standalone file or an archive member.

As you already agreed on, ctypes.util.find_library() indeed should return the 
location of the Shared Object - as either "/path/to/file" or 
"/path/to/file(member)". And ctypes.CDLL() should add the RTLD_MEMBER flag to 
_ctypes.dlopen() if there is the "(member)" part.

However, that does not necessarily mean the RTLD_MEMBER value needs to be 
available through the ctypes API. Instead, RTLD_MEMBER feels more appropriate 
for the _ctypes API - and on AIX only.

Anyway:
Unfortunately, there is no concept of embedding something like ELF's DT_SONAME 
tag into the Shared Object. The very (PATH,BASE,MEMBER) value as (specified to 
and) discovered by the linker is recorded into the just-linked executable (or 
Shared Object). This implies that the runtime loader does search for the very 
same filename (and member eventually) as the linker (at linktime).

However, to still get some kind of shared library versioning, multiple versions 
of one Shared Object are put into one single Archive Library, where the "old" 
versions get the LOADONLY flag set (via 'strip -e') - so executables linked 
against an old version still can load their "old" Shared Object, while the 
linker discovers the "current" version only.

But this "single-filename" based shared library versioning is a huge burden for 
packages managers - either human or software, even when they maintain their 
packages in a private prefix (like /opt/freeware, /usr/local and similar). 
Neither can they put their "current" Shared Object's version into the single 
(system's) Archive Library, nor can they mark existing Shared Objects as 
LOADONLY.
On the other hand, they also do not want to pull all the system versions into 
their own Archive Library.

So for package managers it is crucial to have "multi-filename" based shared 
library versioning instead.

But there is help:
AIX also provides (plain text) "Import Files": They contain a list of symbols 
for the linker, and a (PATH,BASE,MEMBER) tuple naming the Shared Object that 
provides these symbols at runtime.

So yes, Import Files can be used for "multi-filename" based shared library 
versioning.

Thus, libtool now offers the "--with-aix-soname=svr4" configure flag, where 
"libNAME.so.X" really is created as an Archive Library, containing the Shared 
Object "shr.o" with the LOADONLY flag set, and the Import File "shr.imp" 
referring to "libNAME.so.X(shr.o)" for runtime. Combined with the symlink 
"libNAME.so", for the "-lNAME" argument the linker discovers the Import File 
"libNAME.so(shr.imp)" now, while recording "libNAME.so.X(shr.o)" into the 
executable for the runtime loader.
Note that for 64bit the Shared Object and Import File is named "shr_64.o" and 
"shr_64.imp", respectively.

While libtool's "--with-aix-soname=svr4" variant creates "libNAME.a" from 
static Objects only, both libtool's "--with-aix-soname=aix" and 
"--with-aix-soname=both" - for backwards compatibility - create "libNAME.a" for 
traditional "single-filename" based versioning: Without any static Object - as 
even Shared Objects can be linked statically(!). But to statically link the 
Shared Object (as an archive member), neither the LOADONLY flag must be set, 
nor an Import File must be found (as Import Files cannot serve for static 
linking).

And "--with-aix-soname=aix", libtool still creates standalone 
"libNAME.so.X.Y.Z" along the (versioning-wise useless) symlinks.

So it is up to the package manager which "aix-soname" variant to choose within 
its prefix: For example, in Gentoo Prefix I'm using "--with-aix-soname=svr4" 
only.

But still, how to get ctypes.find_library() working - ideally for each variant, 
is another story. Right now it does not work for any variant, but I guess that 
search algorithm should follow how the linker discovers the (PATH,BASE,MEMBER) 
values to write into just-linked executables, combined with how the runtime 
loader finds the Shared Object to actually load.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Haubenwallner]

Changes by Michael Haubenwallner :


--
nosy: +haubi

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt added the comment:

Again, I would like to draw attention to this issue - BECAUSE -

it is possible to use ctypes.CDLL() ASIS, on AIX - however, 
ctypes.util.find_library() always seems to fail (i.e., returns None even when a 
.so file exists)

When the library names are hard-coded, rather than found by find_library() 
everything seems to work fine.

In short, I hope this will finally be recognized as a bug 
(ctypes.util.find_library()).

Ideally, RTLD_MEMBER logic would be added to the Lib/ctypes/__init__.py so that 
CDLL does not have to have RTLD_MEMBER added manually as it does now.

(I have not yet figured out how to use LibraryLoader() properly, it seems to 
never complain, or behave the same as ctypes.CDLL(None) which returns the 
"python process" namespace - if I understand that correctly.

p.s. a) I have a newer patch; b) PEP 8, etc. pickyness is encouraged (i.e., 
expect multiple iterations before a patch is accepted - I do not mind learning 
PEP 8 et al.);

imho - nothing new is being added to what python2 (and python3!) already can 
do. However, a fix to make it easier and clearer to use (there must be a PEP 
for that case as well) - is warranted.


Preparation:
a) the contents of the archive (example)
root@x064:[/data/prj/python/python-2.7.12.0]ar -Xany tv /usr/lib/libcurses.a
rwxr-xr-x   300/300   499495 Sep 26 22:35 2007 shr42.o
rwxr-xr-x   300/300   321459 Sep 26 22:04 2007 shr4.o
rwxr-xr-x   300/300   197552 Sep 26 22:04 2007 shr.o
rwxr-xr-x   300/300   591888 Sep 26 22:35 2007 shr42_64.o

b) create a empty .so file - MAYBE this will be found by the so-called "posix"
   routine in ctypes.util.find_library

root@x064:[/data/prj/python/python2-2.7.13]touch /usr/lib/libcurses.so

c) A test program
import sys
import ctypes
from ctypes import util

if sys.platform[:3] == "aix":
print ctypes.util.find_library("curses")
RTLD_MEMBER =  0x0004
if (sys.maxsize < 2**32):
print 32
print ctypes.CDLL("libcurses.a(shr.o)", RTLD_MEMBER)
else:
print 64
print ctypes.CDLL("libcurses.a(shr42_64.o)", RTLD_MEMBER)

Testing:
a) notice "None" as value printed by find_library
b) notice that ctypes.CDLL can load the library when RTLD_MEMBER isd added
root@x064:[/data/prj/python/python2-2.7.13]./python ../python2-2.7.13/test*.py
None
64


Changes:
-- since /usr/lib/libcurses.so is an empty file
   MAYBE - that is why the result was None
-- extract the 64-bit member and rename as /usr/lib/libcurses.so
-- test both find_library (still says None!) and CDLL of the extracted member
-- as it also loads, CDLL, i.e., dlopen(), works without RTLD_MEMBER
   (as it should)
-- there does not appear top be anything wrong with ctypes.CDLL,
   but only with the 'utils' included

root@x064:[/data/prj/python/python2-2.7.13]ar x /usr/lib/libcurses.a shr42_64.o
root@x064:[/data/prj/python/python2-2.7.13]mv shr42_64.o /usr/lib/libcurses.so

import sys
import ctypes
from ctypes import util

if sys.platform[:3] == "aix":
print ctypes.util.find_library("curses")
RTLD_MEMBER =  0x0004
if (sys.maxsize < 2**32):
print 32
print ctypes.CDLL("libcurses.a(shr.o)", RTLD_MEMBER)
else:
print 64
print ctypes.CDLL("libcurses.a(shr42_64.o)", RTLD_MEMBER)
print ctypes.CDLL("libcurses.so")

root@x064:[/data/prj/python/python2-2.7.13]./python ../python2-2.7.13/test*.py
None
64



Verification of (expected) behavior:
a) CDLL in both formats returns the same function pointer for 'addch'
b) LibraryLoader always returns something, even when it is nonsense
c) CDLL - fails - aka Traceback - when an argument cannot be loaded

from ctypes import util

if sys.platform[:3] == "aix":
print ctypes.util.find_library("curses")
RTLD_MEMBER =  0x0004
if (sys.maxsize < 2**32):
print 32
print ctypes.CDLL("libcurses.a(shr.o)", RTLD_MEMBER)
else:
print 64
print ctypes.CDLL("libcurses.a(shr42_64.o)", RTLD_MEMBER)
lib = ctypes.CDLL("libcurses.a(shr42_64.o)", RTLD_MEMBER)
if hasattr(lib, 'addch'):
print "addch found"
print lib.addch
else:
print "addch not found"
print ctypes.CDLL(None)
lib = ctypes.CDLL(None)
if hasattr(lib, 'addch'):
print "addch found"
print lib.addch
else:
print "addch not found"
print ctypes.CDLL("libcurses.so")
lib = ctypes.CDLL("libcurses.so")
if hasattr(lib, 'addch'):
print "addch found"
print lib.addch
else:
print "addch not found"
print "LibraryLoader tests"
print ctypes.LibraryLoader("libcurses.so")
lib = ctypes.LibraryLoader("libcurses.so")
print ctypes.LibraryLoader(None)
print ctypes.LibraryLoader("libcurses.a(shr42_64.o)")
print ctypes.LibraryLoader("libc.a(shr_64.o)")
print "LibraryLoader XXX tests show 

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt added the comment:

Considering that python-2.7.13 is posed for a release - I ask again, 
considering that python-2.7.12 (and I expect a few earlier ones) can load "AIX" 
.a type shared libraries - if you know how to supply the name - 

that my patch be included in python-2.7.13.

michael@x071:[/data/prj/python]-2.7.12.0/Lib/ctypes/util.py<
--- python-2.7.12/Lib/ctypes/util.py2016-06-25 21:49:30 +
+++ python-2.7.12.0/Lib/ctypes/util.py  2016-12-02 10:12:01 +
@@ -262,6 +262,10 @@
 print cdll.LoadLibrary("libcrypto.dylib")
 print cdll.LoadLibrary("libSystem.dylib")
 print cdll.LoadLibrary("System.framework/System")
+if sys.platform == "aix5":
+from ctypes import CDLL
+RTLD_MEMBER =  0x0004
+print CDLL("libc.a(shr_64.o)", RTLD_MEMBER)
 else:
 print cdll.LoadLibrary("libm.so")
 print cdll.LoadLibrary("libcrypt.so")

And the result is:

root@x064:[/data/prj/python/python-2.7.12.0/Lib/ctypes]../../python util.py
None
None
None


In, other words, as is, find_library() will always return None for standard 
libraries (will only return a value if "root" has extracted and renamed a 
shared library member as a file) - while, if you know the magic that 
find_library cannot return - you can load such a library.

IMVHO (in my Very humble opinion) - a bug that has been too long unnoticed - 
but can be repaired.

There is no additional ability being added - it is already there. Just making 
it more accessible and legible for python programmers on AIX.

If the patch-code needs more cleanup, improvement, etc. - fine. But do not lock 
out an easy interface to such a basic function.

regards,
Michael

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Changes by Michael Felt :


Added file: http://bugs.python.org/file44869/_aix.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt added the comment:

The "core" changes in this patch are very simple - in parallel with the way 
find_library() is managed in util.py



a) __init__.py:
   add an additional mode bit for call to dlopen() (in __init__.py)
diff -u src/Python-2.7.12/Lib/ctypes/__init__.py 
python-2.7.12.2/Lib/ctypes/__init__.py
--- src/Python-2.7.12/Lib/ctypes/__init__.py2016-06-25 21:49:30 +
+++ python-2.7.12.2/Lib/ctypes/__init__.py  2016-09-28 12:55:15 +
@@ -352,6 +352,16 @@
 flags |= _FUNCFLAG_USE_ERRNO
 if use_last_error:
 flags |= _FUNCFLAG_USE_LASTERROR
+if _sys.platform.startswith("aix"):
+"""When the name contains ".a(" and ends with ")",
+   asin "libFOO.a(libFOO.so)" this is taken to be an
+   archive(member) syntax for dlopen(), and the mode is adjusted.
+   Otherwise, name is presented to dlopen() as a file argument.
+"""
+# from _ctypes import RTLD_NOW - not until Python3.7
+if name and name.endswith(")") and ".a(" in name:
+RTLD_MEMBER = 0x0004
+mode |= RTLD_MEMBER

 class _FuncPtr(_CFuncPtr):
 _flags_ = flags

b) util.py:
   determine that is is not generic posix and call and import
   and execute an external .py file
c) some prettier (optional!) print statements in self-test

diff -u src/Python-2.7.12/Lib/ctypes/util.py python-2.7.12.2/Lib/ctypes/util.py
--- src/Python-2.7.12/Lib/ctypes/util.py2016-06-25 21:49:30 +
+++ python-2.7.12.2/Lib/ctypes/util.py  2016-09-28 08:41:57 +
@@ -81,6 +81,14 @@
 continue
 return None

+if sys.platform.startswith("aix"):
+# find .so members in .a files
+# using dump loader header information + sys.
+import ctypes._aix as aix
+
+def find_library(name):
+return aix.find_library(name)
+
 elif os.name == "posix":
 # Andreas Degert's find functions, using gcc, /sbin/ldconfig, objdump
 import re, tempfile, errno
@@ -247,10 +255,11 @@
 print find_library("msvcrt")

 if os.name == "posix":
-# find and load_version
-print find_library("m")
-print find_library("c")
-print find_library("bz2")
+# find
+print("m\t:: %s" % find_library("m"))
+print("c\t:: %s" % find_library("c"))
+print("bz2\t:: %s" % find_library("bz2"))
+print("crypt\t:: %s" % find_library("crypt"))

 # getattr
 ##print cdll.m
@@ -262,6 +271,12 @@
 print cdll.LoadLibrary("libcrypto.dylib")
 print cdll.LoadLibrary("libSystem.dylib")
 print cdll.LoadLibrary("System.framework/System")
+elif sys.platform.startswith("aix"):
+print("crypto\t:: %s" % cdll.LoadLibrary(find_library("crypto")))
+if (sys.maxsize < 2**32):
+print("c\t:: %s" % cdll.LoadLibrary("libc.a(shr.o)"))
+else:
+print("c\t:: %s" % cdll.LoadLibrary("libc.a(shr_64.o)"))
 else:
 print cdll.LoadLibrary("libm.so")
 print cdll.LoadLibrary("libcrypt.so")


d) in test_loading.py say test is failed if find_library does not find
   at least one library

diff -u src/Python-2.7.12/Lib/ctypes/test/test_loading.py 
python-2.7.12.2/Lib/ctypes/test/test_loading.py
--- src/Python-2.7.12/Lib/ctypes/test/test_loading.py   2016-06-25 21:49:30 
+
+++ python-2.7.12.2/Lib/ctypes/test/test_loading.py 2016-09-28 12:43:46 
+
@@ -11,6 +11,11 @@
 libc_name = "coredll"
 elif sys.platform == "cygwin":
 libc_name = "cygwin1.dll"
+elif sys.platform.startswith("aix"):
+if (sys.maxsize < 2**32):
+libc_name = "libc.a(shr.o)"
+else:
+libc_name = "libc.a(shr_64.o)"
 else:
 libc_name = find_library("c")

@@ -38,11 +43,16 @@
 self.assertRaises(OSError, cdll.LoadLibrary, self.unknowndll)

 def test_find(self):
+# to track that at least one call to find_library() found something
+found = False
 for name in ("c", "m"):
 lib = find_library(name)
 if lib:
+found = True
 cdll.LoadLibrary(lib)
 CDLL(lib)
+# test is FAILED if nothing was found
+self.assertTrue(found)

 @unittest.skipUnless(os.name in ("nt", "ce"),
  'test specific to Windows (NT/CE)')

Finally - there is the additional file: _aix.py - submitted as an attachment - 
and a patch with them all

--
Added file: http://bugs.python.org/file44868/Python2.7.Lib.ctypes.160928.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt added the comment:

On 23-Aug-16 02:01, Martin Panter wrote:
> Martin Panter added the comment:
Thank you for your reply!
>
> I had understood that changing find_library() would only be useful in 
> combination with the automatic RTDL_MEMBER detection.
Adding the RTLD_MEMBER to the mode would be necessary for support of 
native archives. Without it, dlopen() will not work.
If I understand your comments correctly a python programmer could change 
all blocks such as: (please forgive syntax errors, if I make one, I may 
miss a : or the indent might not be straight)

Now:
xxxdl = cdll.LoadLibrary(find_library("xxx"))

Patched:
if sys.platform.startswith("aix"):
 dlname = find_library("xxx")
 if dlname and dlname.endswith(")") and dlname.rfind(".a(") > 0:
 from _ctypes import RTLD_LOCAL, RTLD_GLOBAL
 mode = RTLD_LOCAL | 0x0004
 xxxdl = cdll.LoadLibrary(dlname, mode)
 else if dlname:
 xxxld = cdll.LoadLibrary(dlname)
 else:
 xxxdl = cdll.LoadLibrary(find_library("xxx"))

> If you want to mention lack of support for AIX in the documentation, that is 
> okay by me. If you want to propose an alternative find_library() 
> implementation _without_ affecting the CDLL behaviour, that may be okay too.
I certainly do not want to document lack of support - I would prefer to 
see belated support for AIX. If the code above is all that is acceptable 
for 2.7 then I am still not as happy as I could be - I would rather not 
require all programmers that are still active in Python2 to add a new 
function to replace the default find_library() - as I think rewriting it 
as a private function is more secure than finding and changing every 
call to ctypes.find_library currently in "my" code.
And, of course, the other change would be everywhere where I now import 
ctypes.util would be to import my own function (that would be the only 
place I imports ctypes.
In short, what I hope for is that the "Now:" codeblock above will work asis.
>
> For the libuuid problem, for 2.7 I would suggest adding an explicit call to 
> load libc.a(. . .) or whatever is appropriate.
Again, without also adding the constant 0x0004 adding an explicit 
call to "libc.a(shr.o)" (32-bit mode) or "libc.a(shr_64.o)" is pointless.
And, if you would permit the constant 0x0004 in Lib/uuid.py to make 
those calls work, then why not let it be in Lib/ctypes/__init__.py ?

>
> Personally I don’t have a specific interest in AIX, but I am happy to commit 
> patches for AIX if I think they are sensible. I think I mentioned before in 
> the other bug that your changes seemed okay for the next Python version.
If I recall, I submitted patches but not processed via Mercurial - not 
had the time to learn that.

I see (now) that you have processed them, and set them for review - many 
thanks.

I do not have any specific interest in python. My interest is supporting 
people who want to use python on AIX. And as PEP 373 says Python is 
supported into/until 2020 - it seems reasonable to correct an omission. 
A computer does not care whether the block is "Now:" or "Patched:". But 
I think most python developers would prefer not having to patch all 
their code. Rather, I fear they will say "we cannot/do not support AIX" 
because ... (some politically correct answer to not say AIX support is 
broken).

> The beta deadline for 3.6 is in a few weeks (PEP 494), although after that 
> there is still 3.7.
Again, I submitted something. It probably needs changes. I'll check the 
review. What else is needed for that to be accepted?

If it misses 3.6, then I will have some soul searching to do.
>
> --
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Martin Panter]

Martin Panter added the comment:

I had understood that changing find_library() would only be useful in 
combination with the automatic RTDL_MEMBER detection. If you want to mention 
lack of support for AIX in the documentation, that is okay by me. If you want 
to propose an alternative find_library() implementation _without_ affecting the 
CDLL behaviour, that may be okay too.

For the libuuid problem, for 2.7 I would suggest adding an explicit call to 
load libc.a(. . .) or whatever is appropriate.

Personally I don’t have a specific interest in AIX, but I am happy to commit 
patches for AIX if I think they are sensible. I think I mentioned before in the 
other bug that your changes seemed okay for the next Python version. The beta 
deadline for 3.6 is in a few weeks (PEP 494), although after that there is 
still 3.7.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt added the comment:

On 22-Aug-16 04:04, Martin Panter wrote:
> Martin Panter added the comment:
>
> The ctypes tests all seem to be protected with code that checks for None, and 
> explicitly skip the test in that case. The skip message should be visible 
> when you run the test in verbose mode.
So at least test/test_something.py run cleanly - but why accept code 
that always returns None - for find_library().

Rather than "hard-code" proper strings in a test - shouldn't the test be 
demonstrating the "failure" of find_library() to return a suitable 
response - when it should not be None.

For example, on AIX the IBM provided /usr/lib/libm.a only has static 
members. So, what has always been wrong (and noone noticed, or is it 
noone cared) the "built-in" test in util.py has, and does, always fail:

root@x064:[/data/prj/aixtools/python/python-2.7.12.0/Lib/ctypes]../../python 
util.py
None
None
None
Traceback (most recent call last):
   File "util.py", line 271, in 
 test()
   File "util.py", line 266, in test
 print cdll.LoadLibrary("libm.so")
   File 
"/data/prj/aixtools/python/python-2.7.12.0/Lib/ctypes/__init__.py", line 
440, in LoadLibrary
 return self._dlltype(name)
   File 
"/data/prj/aixtools/python/python-2.7.12.0/Lib/ctypes/__init__.py", line 
362, in __init__
 self._handle = _dlopen(self._name, mode)
OSError:0509-022 Cannot load module .
 0509-026 System error: A file or directory in the path name 
does not exist.

The documentation says:

The exact functionality is system dependent.

On Linux, |find_library()| tries to run external programs 
(|/sbin/ldconfig|, |gcc|, and |objdump|) to find the library file. It 
returns the filename of the library file.
...
On OS X, |find_library()| tries several predefined naming schemes and 
paths to locate the library, and returns a full pathname if successful:
...
On Windows, |find_library()| searches along the system search path, and 
returns the full pathname, but since there is no predefined naming 
scheme a call like |find_library("c")| will fail and return |None|.

Are you saying the documentation should be updated to read:
On AIX, find_library tries to use the Linux code which generally fails 
and will return None.

And the closing bit:
If wrapping a shared library with |ctypes| 
, it /may/ 
be better to determine the shared library name at development time, and 
hardcode that into the wrapper module instead of using |find_library()| 
to locate the library at runtime (so forget about developing code for 
multiple platforms - find_library() cannot give you that support.
p.s. On AIX, you must use a hard-coded name to ctypes.CDLL() - and also 
add an extra flag - because even though we said "the exact functionality 
is system dependent" we do not permit new systems to add corrections.

I apologize that my frustration is more than peeking through. But I am 
frustrated. find_library(), unless I completely misunderstand the 
documentation, is a helper function to releave the programmer of needing 
to know the specifics of multiple platforms. My frustration is 
heightened by what I read about the issues with "uuid" - which also 
calls find_library() - so again, on AIX it always returns None -- a) 
find_library is broken; b) there is no libuuid.so or libuuid.a on AIX 
(and c) 4 of the 5 programs also called do not exist on AIX, and the one 
that does generates a different string than is compared to).

I understand - AIX has not been a major (user) platform for python. I am 
amazed that noone from IBM (AIX) development has never shown more interest.
Disclaimer: yes, I work for IBM - but am not a developer. Customers do 
ask me about "why is python so old, why does it not work with XXX" - and 
only because I am inclined to "get to the bottom" did I even start on this.

If the root cause is: "IBM showed no interest X years ago and we, 
python, have no interest now in IBM or AIX" then please just say so - 
and I shall do other things with my time.

In closing - I thought python was multi-platform and I had hoped to be 
of some help in improving python integration with the platform AIX. 
Please, one way or the other, help me lessen my frustration.

Thank you for your time and patience with my rant!

> We could avoid skipping these tests in 2.7 by adding a special case for AIX 
> that loads the library via CDLL("libc.a(shr[_64].o)", RTLD_MEMBER). Like an 
> extension of the special cases already at 
> ,
>  but we have to set the RTLD_ flag as well as the library name.
>
> --
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Martin Panter]

Martin Panter added the comment:

The ctypes tests all seem to be protected with code that checks for None, and 
explicitly skip the test in that case. The skip message should be visible when 
you run the test in verbose mode.

We could avoid skipping these tests in 2.7 by adding a special case for AIX 
that loads the library via CDLL("libc.a(shr[_64].o)", RTLD_MEMBER). Like an 
extension of the special cases already at 
,
 but we have to set the RTLD_ flag as well as the library name.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt added the comment:

The more common TESTED "behavior" issue is simply:

find_library("c") always returns None while it should be returning 
either libc.a(shr.o) in 32-bit mode and libc.a(shr_64.o) in 64-bit mode. 
If that gets corrected, then adding RTLD_MEMBER it's numerical 
equivalent is also needed.

michael@x071:[/home/michael]grep RTLD_MEMBER /usr/include/*.h
/usr/include/dlfcn.h:#defineRTLD_MEMBER 0x0004 /* 
Module name may indicate

I mention find_library("c") specifically as that is used as a core test 
in both Lib/ctypes/utils.py as well as the following tests in 
Lib/ctypes/test/*.py:

test_callback.py, test_error.py and test_loading.py

How can a test that is always returned None really be testing anything. 
In any case, what these test are "testing" something very different on 
AIX compared to Linux (and perhaps Solaris and OS/X).

So, how is the current behavior not a "bug" (that, for ages, has either 
been ignored and/or not understood  - and I go more for the later, as 
there have been a few issues re: performance concerns because ldconfig 
is (generally) not available on AIX. Again, the net result of 
find_library() is for default installs - to return None even when a real 
value should be returned.

On 11-Aug-16 17:10, Michael Felt wrote:
> Martin Panter added the comment:
> >
> >For 2.7, adding the automatic RTLD_MEMBER mode does not seem like a bug fix 
> >to me. Currently, I understand this code could load two separate libraries:
> >

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt added the comment:

On 02-Aug-16 15:34, Martin Panter wrote:
> Martin Panter added the comment:
>
> For 2.7, adding the automatic RTLD_MEMBER mode does not seem like a bug fix 
> to me. Currently, I understand this code could load two separate libraries:
>
> file = CDLL("libcrypto.a(libcrypto.so.1.0.0)")
Noone (in their right mind, imho) would install, or extract the archive 
member libcrypto.so.1.0.0and then rename it 
/usr/lib/libcrypto.a(libcrypto.so.1.0.0)

FYI - I did test this case, and as a file, without 0x00040 (aka 
RLTD_MEMBER) or'd into the mode.
> member = CDLL("libcrypto.a(libcrypto.so.1.0.0)", DEFAULT_MODE | 0x0004)
>
> With your proposed change, the first line will do the same as the second 
> line, and Python will no longer provide a way to load a file named like in 
> the first operation. Maybe this is okay for the next version of Python 3 
> (because it is only breaking a rare corner case), but my view is it is not 
> worth changing 2.7.
Right now it is broken in AIX - it is impossible to use the native 
archive(member) support. Direct loading of .so files, if I recall 
correctly, was to provide linux affinity (remember the L in AIX 5L).

I believe python2 has some years to go, and basically, you ask anyone 
using python on AIX to go through all kinds of loops. This hurts python 
acceptance on AIX - too much work to get it working and keep it working.

I have been providing AIX support for over 20 years - NEVER have I seen 
anyone name a shared library libxxx.a(libxxx.so). What I have seen is 
that people extract archive members from a .a archive into the same 
directory - but when the archive gets updated most forget to extract the 
members again.

In yet another case I have seen a case where they copied everything to a 
new directory and do a chroot() to get the .so files they want - because 
it is impossible to load from a .a file.

Yes, when I first started back in February and March: a) knew next to 
nothing about python; b) was trying to solve it in ways I would like it 
be (mainly more flexible aka smarter re: the argument to find_library().

However, I do believe what I have here does what is done for other 
platforms (e.g., darwin needs a different name ending, just not a 
different mode to go with it) - will "fix" all "performance" related 
issues for AIX re: calling ldconfig (which is only available in 
extremely rare situations - again I have never seen it - because, by 
default, even gcc is using AIX ld, not GNU ld)

I hope saying "please" helps. Without it, the AIX implementation is 
non-existant. The linux code is called for AIX because that is the last 
else: block, not because the code is specific to "posix".

so - PLEASE - pretty please!

Michael

p.s. And I shall look at the mercurial pages - and I hope have it working.
>
> --
> nosy: +martin.panter
> title: ctypes and AIX - also for 2.7.X (and later) -> ctypes library loading 
> and AIX - also for 2.7.X (and later)
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Martin Panter]

Martin Panter added the comment:

If you are still figuring out Mercurial, maybe see 
 and 
 if you haven’t already.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Martin Panter]

Martin Panter added the comment:

For 2.7, adding the automatic RTLD_MEMBER mode does not seem like a bug fix to 
me. Currently, I understand this code could load two separate libraries:

file = CDLL("libcrypto.a(libcrypto.so.1.0.0)")
member = CDLL("libcrypto.a(libcrypto.so.1.0.0)", DEFAULT_MODE | 0x0004)

With your proposed change, the first line will do the same as the second line, 
and Python will no longer provide a way to load a file named like in the first 
operation. Maybe this is okay for the next version of Python 3 (because it is 
only breaking a rare corner case), but my view is it is not worth changing 2.7.

--
nosy: +martin.panter
title: ctypes and AIX - also for 2.7.X (and later) -> ctypes library loading 
and AIX - also for 2.7.X (and later)

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com