[issue34194] test_ssl, AIX, and defaults for _ssl connections

[Michael Felt]

Michael Felt  added the comment:

update: went back to check what worked, did not work without the environment 
variable set.

I am going to guess that pip(3) is able to make use of the environment variable 
SSL_CERT_FILE as pip download fails (in some cases) without it, but succeeds 
with it.

I thought to recall something similar while using git (mine leaning on 
python2-2.7) but I have not had the time to test it again (using git fetch and 
git pull from cpython).

--

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

[issue34194] test_ssl, AIX, and defaults for _ssl connections

[Michael Felt]

Michael Felt  added the comment:

Any comments re: environment variables - even if the answer is None!

--
versions: +Python 2.7, Python 3.8

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

[issue21826] Performance issue (+fix) AIX ctypes.util with no /sbin/ldconfig present

[Michael Felt]

Michael Felt  added the comment:

as this is fixed is Python3.7 (see issue26439) and has been stated several 
times that it will not be fixed in Python2.7 I suspect this issue may also be 
closed.

--

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

[issue34194] test_ssl, AIX, and defaults for _ssl connections

[Michael Felt]

New submission from Michael Felt :

As far as I can tell _ssl works properly. However, test_ssl returns FAIL at 
some very basic levels, e.g.
...
test_constructor (test.test_ssl.ContextTests) ... ERROR
...
test_protocol (test.test_ssl.ContextTests) ... ERROR
test_python_ciphers (test.test_ssl.ContextTests) ... ok
test_session_stats (test.test_ssl.ContextTests) ... ERROR

When using applications that depend on python (e.g., git) and getting "SSL" 
related errors - doing 

export SSL_CERT_FILE=/var/ssl/somefile.pem

the problems go away. However, it looks asif that variable is not being used by 
python (3.7).

Given: AIX openssl does not have a default CAFile nor CAPath, etc., only that 
openssl.cnf is at /var/ssl/openssl.cnf. Also - AIX openssl.base does not 
include any certificates.

Question: does python have a documented (or undocumented) env variable it uses 
to look for, provide, or override a system/distribution default?

--
assignee: christian.heimes
components: Library (Lib), SSL, Tests
messages: 322180
nosy: Michael.Felt, christian.heimes
priority: normal
severity: normal
status: open
title: test_ssl, AIX, and defaults for _ssl connections
type: behavior
versions: Python 3.7

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

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt  added the comment:

OK. as promised when I closed PR 5183 - a restart.

You may skip the wall that follows - it is just documentation.

The key points:
* AIX ifconfig and arp do not supply maccaddr
* netstat supplies a macaddr, but uses '.' not ':' as a delimiter
** also, AIX netstat value is not always 17 characters (dec 15 is 'f' not '0f')
* since Python3-3.7 there is support for _uuid so test_unix_getnode passes 
"WithExtModule" but fails "WithoutExtModule"

A minor point:
test_find_mac() has always passed on AIX because the test was passed a
macaddr using ':' and tested for ':'. The test has been modified to provide a 
macaddr in "AIX" format. IMHO - the test would be better if the string was not 
"forced to be 17 characters" (e.g., this is my macaddr as returned by netstat: 
"0.12.a3.53.c9.46"

My question - getting back to what I had done previously - even though _uuid is 
working, should the "WithoutExtModule" and support for test_find_mac() be 
adjusted in uuid.py - OR - are these errors in test just going to be accepted 
asis?

Details: (skip the wall :p )


So, with only test_uuid.py patched, the verbose returns ('ok' tests not 
included!):

root@x066:[/data/prj/python/python3-3.8]./python 
../git/**3.8/Lib/test/regrtest.py -v test_uuid | egrep -v "ok$"
== CPython 3.8.0a0 (default, Jul 20 2018, 00:54:36) [C]
== AIX-1-00C291F54C00-powerpc-32bit big-endian
== cwd: /data/prj/python/python3-3.8/build/test_python_11468890
== CPU count: 4
== encodings: locale=ISO8859-1, FS=iso8859-1
Run tests sequentially
0:00:00 [1/1] test_uuid
test_arp_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'because AIX "arp" does not provide macaddr'
test_find_mac (test.test_uuid.TestInternalsWithExtModule) ... FAIL
test_ifconfig_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'because AIX "ifconfig" does not provide macaddr'
test_ip_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires ip'
test_ipconfig_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires Windows'
test_lanscan_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires lanscan'
test_netbios_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires win32wnet'
test_netstat_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires netstat'
test_windll_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires Windows'
test_arp_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'because AIX "arp" does not provide macaddr'
test_find_mac (test.test_uuid.TestInternalsWithoutExtModule) ... FAIL
test_ifconfig_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... 
skipped 'because AIX "ifconfig" does not provide macaddr'
test_ip_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires ip'
test_ipconfig_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... 
skipped 'requires Windows'
test_lanscan_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires lanscan'
test_netbios_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires win32wnet'
test_netstat_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires netstat'
test_unix_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires uuid_generate_time'
test_windll_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires Windows'
test_uuid1_safe (test.test_uuid.TestUUIDWithExtModule) ... skipped 'requires 
uuid_generate_time_safe(3)'
test_uuid1_bogus_return_value (test.test_uuid.TestUUIDWithoutExtModule) ... 
skipped 'need uuid._generate_time_safe'
test_uuid1_is_safe (test.test_uuid.TestUUIDWithoutExtModule) ... skipped 'need 
uuid._generate_time_safe'
test_uuid1_is_unsafe (test.test_uuid.TestUUIDWithoutExtModule) ... skipped 
'need uuid._generate_time_safe'
test_uuid1_safe (test.test_uuid.TestUUIDWithoutExtModule) ... skipped 'requires 
uuid_generate_time_safe(3)'
test_uuid1_unknown (test.test_uuid.TestUUIDWithoutExtModule) ... skipped 'need 
uuid._generate_time_safe'
test test_uuid failed

==
FAIL: test_find_mac (test.test_uuid.TestInternalsWithExtModule)
--
Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/test/test_uuid.py", line 548, in 
test_find_mac
self.assertEqual(mac, 0x1234567890ab)
AssertionError: None != 20015998341291

==
FAIL: test_find_mac (test.test_uuid.TestInternalsWithoutExtModule)
--
Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/tes

[issue34163] Python latest release 2.7 shows SSL error

[Michael Felt]

Michael Felt  added the comment:

There is a big chance it is not a direct issue with either python or pip / 
rather an issue with how current your "openssl" setup is.

As an example, using git I was not able to "pull" from a remote. This git (that 
also depends on python) has been working for ages. I "fixed" it by getting an 
updated "global" cacert.pem "chain of trust" installed and now https://... 
queries were working instantly.

So, did you perhaps, also update your SSL while re-installing/updating python2? 
(And also note, v2.7.10 is several years old. The latest v2.7 version is 
2.7.15).

--
nosy: +Michael.Felt

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

[issue11191] test_search_cpp error on AIX (with xlc)

[Michael Felt]

Michael Felt  added the comment:

@tarek - anything specific/extra you need?

--

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

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Michael Felt  added the comment:

Again, the PR worked months ago. I expect it to still work.

So, I guess the question is: is there any interest. After several weeks of 
waiting after the last ttt - still waiting :)

--
components: +Tests -ctypes

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

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

[Michael Felt]

Michael Felt  added the comment:

imho - this should have status "closed"

--

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

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt  added the comment:

I was not aware that _uuid was new to python3-3.7. I thought it had been around 
for a long time. 

Bpo-28009 goes back two years and i was unaware of uuid_create(). 

Would it be easier to split it into 3 issues? One for unixdll, one for netstat, 
and one for test_uuid?

Michael

Sent from my iPhone

> On 10 Jun 2018, at 13:52, STINNER Victor  wrote:
> 
> 
> STINNER Victor  added the comment:
> 
>> As noted on PR 7511 and PR 7567, I have merged Michael's configure.ac fixes 
>> for testing for uuid_enc_be availability (independent of platform) that were 
>> incorrect in earlier commits for this issue.  Merged for 3.7.0rc1 and master 
>> (3.8). Thanks, everyone!
> 
> Thanks you Ned and Michael. Sorry for the confusion. I was first confused 
> that the fix for master added a lot of code using ctypes. The final fix is 
> the right fix for 3.7 and master ;-)
> 
> Michael: if you want to fix uuid on 3.6, I would suggest to open a new issue, 
> because it seems that the fix is much more complex and unrelated to _uuid 
> (module added to Python 3.7).
> 
> --
> 
> ___
> Python tracker 
> <https://bugs.python.org/issue32493>
> ___
>

--

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

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt  added the comment:

OK. I know I do not understand this well - when it goes in A, or B.

So, if I understand correctly, like this issue was created after 
uuid_create() was added for AIX and created issues for FreeBSD )that I 
did not know had uuid_create(), I need to create a new issue where I say 
this issue created an issue for AIX?

Seems like a lot of work. I only put it here because it is a very simple 
change directly related to the last PR.

Just verify that is what you want and I'll get to it as I can. In any 
case, I'll pull the PR - as it is specific to AIX.

On 6/8/2018 12:48 AM, STINNER Victor wrote:
> STINNER Victor  added the comment:
>
>> @vstinner - I know this is "closed", however, I submit a minor PR to fix an 
>> error in PR7104. The logic of configure.ac always defines HAVE_UUID_ENC_BE. 
>> I cannot proceed with PR5183 (aka issue28009) until this is repaired.
> The title of this issue makes it very specific to FreeBSD, so it would be 
> better to create a new one for AIX. What your write for the commit 
> description is not appropriate for a commit, but it's fine for the 
> description of a bug.
>
> Please open a new issue to track uuid changes for AIX. I know that you have a 
> second one for Python <= 3.6.
>
> --
> resolution: fixed ->
> status: closed -> open
>
> ___
> Python tracker 
> <https://bugs.python.org/issue32493>
> ___
>

--

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

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt  added the comment:

@vstinner - I know this is "closed", however, I submit a minor PR to fix an 
error in PR7104. The logic of configure.ac always defines HAVE_UUID_ENC_BE.

I cannot proceed with PR5183 (aka issue28009) until this is repaired.

Thx!

--

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

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Change by Michael Felt :


--
pull_requests: +7139

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

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Change by Michael Felt :


--
pull_requests: +7082

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

[issue11191] test_search_cpp error on AIX (with xlc)

[Michael Felt]

Michael Felt  added the comment:

I hope this can be reviewed and eventually closed - not because it is X years 
old and unresolved - but because it is resolved for the latest branches!

Thx

--
versions: +Python 3.8

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

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt  added the comment:

Please review PR. at least for "master"

--
versions: +Python 3.8

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

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Michael Felt  added the comment:

I know it is not earth shattering - but it will permit one more test to pass. 
Please review the PR. Thx.

--
versions: +Python 3.8

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

[issue27632] build on AIX fails when builddir != srcdir, more than bad path to ld_so_aix

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Wishing I could edit a post...

root@x066:[/data/prj/python]find ./python3-3.4.8 git/python3-3.4.8 -name 
ld_so_aix
./python3-3.4.8/Modules/ld_so_aix

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27632>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27632] build on AIX fails when builddir != srcdir, more than bad path to ld_so_aix

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

OOT builds are working for Python2.7, Python3-3.5, Python3-3.6 (and later I 
expect) but not for Python3-3.4(.8)

unable to execute '../git/python3-3.4.8/Modules/ld_so_aix': No such file or 
directory

while building OOT
root@x066:[/data/prj/python]ls -ld ./python3-3.4.8 git/python3-3.4.8
drwxr-sr-x   12 root 1954   4096 May 13 16:07 ./python3-3.4.8
drwxrwsr-x   16 199  1954   4096 May 13 15:37 git/python3-3.4.8

Sigh. So close!

--
versions: +Python 3.4

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27632>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33464] AIX and "specialized downloads" links

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Took me a while to get this 'posted' properly.

- please see https://github.com/python/pythondotorg/issues/1156

My apologies for the noise.

--
stage:  -> resolved
status: open -> closed

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33464>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33464] AIX and "specialized downloads" links

[Michael Felt]

Michael Felt <aixto...@gmail.com> added the comment:

P.s. i apologize for probably posting in the incorrect “issues” area. Having 
followed guido’s link i see an area that is new for me. 

If it is better that i “restart” the discussion there, just ask.

--
nosy: +aixto...@gmail.com

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33464>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33464] AIX and "specialized downloads" links

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

FYI: as my primary effort for AIX concerned ctypes.find_library() - and that is 
now in the Python3-3.7 branch - when I do a PR it will only be for "current" 
efforts, i.e., Python3-3.7 and later.

As much as I feel it is important I'll backport myself into branches I'll label 
"aix.vX.Y.Z", where the starting point is always anew from vX.Y.Z

More detailed: (e.g., on 3.4.8, which I am working on now)

git clone -b v3.4.8 g...@github.com:aixtools/cpython.git python-3.4.8
git branch aix.v3.4.8
cat ../aix.patch | patch ...
make and test
git commit -m"my message"
git push to_my_fork

As much as possible, I want to be in sync with python - and give you the option 
of including anything AIX.

As counts for most, if not all, this is "free-time", not paid - but I will 
always try to respond to questions re: AIX.

Guido - thank you for the support!

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33464>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33464] AIX and "specialized downloads" links

[Michael Felt]

New submission from Michael Felt <mich...@felt.demon.nl>:

I struggled with how python was packaged by others. Key points being: many 
dependencies, no assurance you could uninstall the dependencies and/or python.

A little over two years ago I started looking for 'root causes' of problems 
that potential users of python (on AIX) were having.

To me it is clear that the packaging problems from two years back are just as 
alive as they were in 2015 and 2016. Since then I have learned a few things 
about python (thanks to all who helped). I would like to apply this knowledge 
and provide a 'cleaner' packaging of Python for AIX - both Python3 and Python2.

I would appreciate my downloadable packages being listed on the "other" 
downloads list. If you wanted to make it complete - the other two I know of are 
Perzl's site (http://www.perzl.org/aix/index.php?n=main.python), and, of 
course, the IBM AIX Toolbox 
(https://www-03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html#P).

I have involved (currently managed and run it) an AIX portal since 2001 - 
http://www.rootvg.net. The last 5 or 6 years I have been hosting a second 
portal I call "aixtools".

In short, I hope you will consider adding - at least - my aixtools wiki pages: 
http://www.aixtools.net/index.php/python3 and 
http://www.aixtools.net/index.php/python (for python2).

Many thanks for your consideration,

Michael

--
messages: 316395
nosy: Michael.Felt, gvanrossum
priority: normal
severity: normal
status: open
title: AIX and "specialized downloads" links
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33464>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33281] ctypes.util.find_library not working on macOS

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 15/04/2018 07:56, Ned Deily wrote:
> Ned Deily <n...@python.org> added the comment:
>
> Thanks for the report and the good detective work!  I see the same results.  
> It appears that the error was introduced by 
> c5ae169e1b73315672770517bf51cf8464286c76 for Issue26439.  It looks we need 
> both a fix and a test for this.  This really needs to be fixed for 3.7.0b4.

Perhaps he can give a bit more info. I do not understand how this could 
break things, as the darwin code is earlier in the queue.

if os.name == "posix" and sys.platform == "darwin":
     from ctypes.macholib.dyld import dyld_find as _dyld_find
     def find_library(name):
     possible = ['lib%s.dylib' % name,
     '%s.dylib' % name,
     '%s.framework/%s' % (name, name)]
     for name in possible:
     try:
     return _dyld_find(name)
     except ValueError:
     continue
     return None

if sys.platform.startswith("aix"):
     # AIX has two styles of storing shared libraries
     # GNU auto_tools refer to these as svr4 and aix
     # svr4 (System V Release 4) is a regular file, often with .so as suffix
     # AIX style uses an archive (suffix .a) with members (e.g., shr.o, 
libssl.so)
     # see issue#26439 and _aix.py for more details

     from ctypes._aix import find_library

elif os.name == "posix":
     # Andreas Degert's find functions, using gcc, /sbin/ldconfig, objdump
     import re, tempfile

     def _findLib_gcc(name):

As I understand the code above (and maybe I am wrong) - the code should 
be calling the unchanged routines in the macholib subdirectory. A simple 
test on macOS would be to comment out the two lines

if sys.platform.startswith("aix"):
     from ctypes._aix import find_library

That will "delete" the AIX find_library logic.

In other words - can someone check whether the unchanged 
Lib/ctypes/macholib/* files are being used? And if not, then something 
surprising is preventing that. If they are - no idea how the macholib 
code got effected by this. The goal was to have all changes in the 
_aix.py file, rather than in util.py.

>
> --
> nosy: +Michael.Felt, ned.deily, vstinner
> priority: normal -> release blocker
> stage:  -> needs patch
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue33281>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33281>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

oops, sain openbsd, should be freebsd

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32493>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

If it is a bug in OpenBSD how do you propose we "fix" this.

imho, the problem is "outside" python.

however, until it is fixed in openbsd, would you accept an 3error macro that 
prevents the mod from being built on the specific version of openbsd that fails?

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32493>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Change by Michael Felt <mich...@felt.demon.nl>:


--
pull_requests: +5378

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27643>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Change by Michael Felt <mich...@felt.demon.nl>:


--
versions: +Python 3.7

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27643>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Now that it is visible - maybe OpenBSD will treat it as a bug and get 
the "version bits" to work as their man page 
(https://man.openbsd.org/uuid.3) says it does:

  STANDARDS <https://man.openbsd.org/uuid.3#STANDARDS>

The *uuid_compare*(), *uuid_create*(), *uuid_create_nil*(), 
*uuid_equal*(), *uuid_from_string*(), *uuid_hash*(), *uuid_is_nil*(), 
and *uuid_to_string*() functions are compatible with the DCE 1.1 RPC 
specification.

The FreeBSD man page 
(https://www.freebsd.org/cgi/man.cgi?query=uuid_create) says:

*NAME* <https://www.freebsd.org/cgi/man.cgi?query=uuid_create#end>
  *uuid*_*compare*,*uuid*_*create*, 
*uuid*_*create*_*nil*,*uuid*_*equal*,*uuid*_*from*_*string*,
  *uuid*_*hash*,*uuid*_*is*_*nil*,*uuid*_*to*_*string*  -- DCE 1.1 
compliant UUID func-
  tions

Re the DCE 1.1 RPC implementation/description - I found this link:
http://pubs.opengroup.org/onlinepubs/9629399/apdxa.htm

And this comment:

The version number is multiplexed in the 4 most significant bits of the 
*time_hi_and_version* field. UUID version Field 
<http://pubs.opengroup.org/onlinepubs/9629399/apdxa.htm#tagtcjh_35> 
lists currently defined versions of the UUID.

*msb1*  *msb2*  *msb3*  *msb4*  *Version*   *Description*
0   0   0   1   1   DCE version, as specified herein.
0   0   1   0   2   DCE Security version, with embedded 
POSIX UIDs.

So, maybe either, or both: OpenBSD and FreeBSD fix their implementation. 
Problem solved?!

On 1/23/2018 3:34 PM, David CARLIER wrote:
> David CARLIER <devne...@gmail.com> added the comment:
>
> In OpenBSD it s even "worse", the version for each call is random (not a 
> surprise when looking at the source). The question is, do we go back to 
> support only AIX or do we accept somehow wrong version ?
>
> --
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue32493>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32493>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32638] distutils test errors with AIX and xlc

[Michael Felt]

New submission from Michael Felt <mich...@felt.demon.nl>:

While working in issue11191 I found a fix for Python3-3.6 and later for the 
following tests, and later - but not for Python3-3.5

I suppose "we" could ignore the error on Python3-3.5 (as I then have a quick - 
simple - fix for Python3-3.6 and later.

Suggestions, rather - how important are the tests on Python3-3.5?



root@x066:[/data/prj/python/git/x066-python3-3.7]nohup ./python 
Lib/test/test_distutils.py | egrep "^(ERROR|FAIL):"
ERROR: test_run (distutils.tests.test_build_clib.BuildCLibTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_get_outputs 
(distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)

root@x066:[/data/prj/python/python3-3.6.4]nohup ./python 
../src/python3-3.6.4/Lib/test/test_distutils.py | egrep "^(ERROR|FAIL):"
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_get_outputs 
(distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_run (distutils.tests.test_build_clib.BuildCLibTestCase)
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)

root@x066:[/data/prj/python/python3-3.5.4]nohup ./python 
Lib/test/test_distutils.py | egrep "^(ERROR|FAIL):"
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_get_outputs 
(distutils.tests.test_build_ext.ParallelBuildExtTestCase)
FAIL: test_sysconfig_compiler_vars 
(distutils.tests.test_sysconfig.SysconfigTestCase)
FAIL: test_sysconfig_module (distutils.tests.test_sysconfig.SysconfigTestCase)

--
components: Distutils
messages: 310519
nosy: Michael.Felt, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils test errors with AIX and xlc
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32638>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11191] test_search_cpp error on AIX (with xlc)

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Just tested the patch presented.

For Python3-3.6.4 the patch in PR-5206 works as is, however, for Python3-3.5.4 
- the patch to Lib/test/support/__init__.py does not work.

So, for Python3-3.5, Python3-3.6 and Python3-master - the test test_search_cpp 
is resolved.

As that is the "literal" question here - I am removing the patch to 
Lib/test/support/__init__.py so that the same tests fail (for different 
reasons). I'll open a new issue for these tests - so that this PR can be 
applied to all current Python3 branches (and skip the test_search_cpp test when 
the compiler is not gcc on AIX).

HTH!

--
versions: +Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue11191>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 1/17/2018 11:16 AM, David CARLIER wrote:
> David CARLIER <devne...@gmail.com> added the comment:
>
> Might comes from uuid1 function itself ... e.g. line 704 not setting version 
> "field".
IMHO: for uuid1 - the version number should be in the 16 bytes filled by 
uuid_create. The implementation of uuid4() in uuid.py "has to" specify 
the attribute by setting the UUID version attribute to 4, so that when 
an uuid4 instance gets asked it's version it says 4. A random number 
gives no such guarantee.

Taking a hint from the FreeBSD man page for uuid_create() - that says it 
provides a DCE 1.1 RPC implementation - I found this link:
http://pubs.opengroup.org/onlinepubs/9629399/apdxa.htm

Therein:

The timestamp is a 60 bit value. For UUID version 1, this is represented 
by Coordinated Universal Time (UTC) as a count of 100-nanosecond 
intervals since 00:00:00.00, 15 October 1582 (the date of Gregorian 
reform to the Christian calendar).

The version number is multiplexed in the 4 most significant bits of the 
*time_hi_and_version* field. UUID version Field 
<http://pubs.opengroup.org/onlinepubs/9629399/apdxa.htm#tagtcjh_35> 
lists currently defined versions of the UUID.

Again - a random number is not likely to correctly set the 4 most significant 
bits - so another way is needed to make an instance it is version 4.
IMHO - the output of uuid_create should satisfy the needs of uuid version 1.

>
> --
> nosy: +David CARLIER2
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue32493>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32493>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

typo here:

So, I think the AMD64 FreeBSD 10.x Shared 3.x uuid_create() function is wrong 
(if that is what it is using - was it/can it also use the uuid_generate* 
routines?

i.e., does AMD FreeBSD use uuid_create() or uuid_generate() - or can it use 
both?

Could someone with AMD try:
Modules/_uuidmodule.c

 +12  static PyObject *
   +13  py_uuid_generate_time_safe(void)
   +14  {
   +15  uuid_t uuid;
   +16  #ifdef HAVE_UUID_GENERATE_TIME_SAFE
   +17  int res;
   +18
   +19  res = uuid_generate_time_safe(uuid);
   +20  return Py_BuildValue("y#i", (const char *) uuid, sizeof(uuid), res);
   +21  #elif HAVE_UUID_GENERATE_TIME
   +22  uuid_generate_time(uuid);
   +23  return Py_BuildValue("y#O", (const char *) uuid, sizeof(uuid), 
Py_None);
   +24  #elif HAVE_UUID_CREATE
   +25  uint32_t status;
   +26  uuid_create(, );
   +27  return Py_BuildValue("y#i", (const char *) , sizeof(uuid), 
(int) status);
   +28  #else
   +29  #error "no uuid library function available"
   +30  #endif
   +31  }

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32493>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Actually, the libc/libuuid function called should be setting the 
version/variant values as well.

So, I think the AMD64 FreeBSD 10.x Shared 3.x uuid_generate() function is wrong 
(if that is what it is using - was it/can it also use the uuid_generate* 
routines?

FYI:

I notice the AIX include file does not actually define the bits for RFC_4122, 
etc.., but the include file comments does show that the implementation is 
taking them into account.

/** The strlen() of a UUID string (does not include terminating null) */
#define UUID_STRLEN 36
/**
 * Constant value indicating an as-yet undetermined UUID for a thing.  Spells \c
 * "\0\0UUID\x10_\x80UNKNOWN" in ASCII.  Zeroes at the top make it very unlikely
 * to collide with a uuid_create()d value, which puts a timestamp in that spot.
 * The \c "\x10" and \c "\x80" are reserved/version/mask bits that make this
 * conform to the format expected by the uuid.h API.
 */
#define UUID_UNKNOWN (uuid_t){0x, 0x4944, 0x105F, 0x80, 0x55, {0x4E, 
0x4B, 0x4E, 0x4F, 0x57, 0x4E}}
#define UUID_UNKNOWN_STR   "-4944-105f-8055-4e4b4e4f574e"

I wrote a simple program to examine uuid for myself.

Maybe - if you ran a loop (looking at uuid1().variant and uuid1().version you 
could see if there is an incorrect version showing up. Rather than python - 
that would seem to be a library function error.

My very simple program:

cat -n ../x4.py
 1  import _uuid
 2  import uuid
 3  _generate_time_safe = _uuid.generate_time_safe
 4  _has_uuid_generate_time_safe = _uuid.has_uuid_generate_time_safe
 5  uuid_time, _ = _generate_time_safe()
 6
 7  uu1a = uuid.UUID(bytes=uuid_time)
 8  uu1b = uuid.uuid1()
 9  uu4 = uuid.uuid4()
10
11  print("a)uuid1 = %x" % uu1a.int)
12  print("b)uuid1 = %x" % uu1b.int)
13  print("")
14  print("a uuid1 = ",uu1a.fields, uu1a.version, uu1a.variant)
15  print("b uuid1 = ",uu1b.fields, uu1b.version, uu1b.variant)
16  uu1c = uuid.uuid1()
17  print("c uuid1 = ",uu1c.fields, uu1c.version, uu1c.variant)
18  print("")
19  print("  uuid4 = %x" % uu4.int)
20  print("  uuid4 = ",uu4.fields, uu4.version, uu4.variant)
21  print("")
22  uu4 = uuid.uuid4()
23  print("  uuid4 = %x" % uu4.int)
24  print("  uuid4 = ",uu4.fields, uu4.version, uu4.variant)

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32493>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11192] test_socket error on AIX

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

I have tried jumping into the pdp using

but do not come much further in understanding how the expectations expressed in 
these comments are satisfied:

 +2153  # Tests for the sendmsg()/recvmsg() interface.  Where possible, the
 +2154  # same test code is used with different families and types of socket
 +2155  # (e.g. stream, datagram), and tests using recvmsg() are repeated
 +2156  # using recvmsg_into().
 +2157  #
 +2158  # The generic test classes such as SendmsgTests and
 +2159  # RecvmsgGenericTests inherit from SendrecvmsgBase and expect to be
 +2160  # supplied with sockets cli_sock and serv_sock representing the
 +2161  # client's and the server's end of the connection respectively, and
 +2162  # attributes cli_addr and serv_addr holding their (numeric where
 +2163  # appropriate) addresses.
 +2164  #


++ Details ++
14 tests failed again:
test_asyncio test_cmath test_ctypes test_datetime test_distutils
test_httplib test_httpservers test_os test_posix test_socket
test_ssl test_subprocess test_time test_utf8_mode


()
-> super().setUp()
(Pdb) s
--Call--
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2187)setUp()
-> def setUp(self):
(Pdb) l
2182
2183# Time in seconds to wait before considering a test failed, or
2184# None for no timeout.  Not all tests actually set a timeout.
2185fail_timeout = 3.0
2186
2187 -> def setUp(self):
2188self.misc_event = threading.Event()
2189super().setUp()
2190
2191def sendToServer(self, msg):
2192# Send msg to the server.
(Pdb) s
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2188)setUp()
-> self.misc_event = threading.Event()
(Pdb) self

(Pdb) s
--Call--
> /data/prj/python/git/x067-python3-3.7/Lib/threading.py(499)__init__()
-> def __init__(self):
(Pdb) self

(Pdb) dir(self)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', 
'__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', 
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', 
'__str__', '__subclasshook__', '__weakref__', '_reset_internal_locks', 'clear', 
'isSet', 'is_set', 'set', 'wait']
(Pdb) l
494
495 """
496
497 # After Tim Peters' event class (without is_posted())
498
499  -> def __init__(self):
500 self._cond = Condition(Lock())
501 self._flag = False
502
503 def _reset_internal_locks(self):
504 # private!  called by Thread._reset_internal_locks by 
_after_fork()
(Pdb) n
> /data/prj/python/git/x067-python3-3.7/Lib/threading.py(500)__init__()
-> self._cond = Condition(Lock())
(Pdb) n
> /data/prj/python/git/x067-python3-3.7/Lib/threading.py(501)__init__()
-> self._flag = False
(Pdb) n
--Return--
> /data/prj/python/git/x067-python3-3.7/Lib/threading.py(501)__init__()->None
-> self._flag = False
(Pdb) n
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2189)setUp()
-> super().setUp()
(Pdb) l
2184# None for no timeout.  Not all tests actually set a timeout.
2185fail_timeout = 3.0
2186
2187def setUp(self):
2188self.misc_event = threading.Event()
2189 -> super().setUp()
2190
2191def sendToServer(self, msg):
2192# Send msg to the server.
2193return self.cli_sock.send(msg)
2194
(Pdb) s
--Call--
> /data/prj/python/git/x067-python3-3.7/Lib/unittest/case.py(453)setUp()
-> def setUp(self):
(Pdb) l
448 called after tearDown on test failure or success.
449
450 Cleanup items are called even if setUp fails (unlike 
tearDown)."""
451 self._cleanups.append((function, args, kwargs))
452
453  -> def setUp(self):
454 "Hook method for setting up the test fixture before exercising 
it."
455 pass
456
457 def tearDown(self):
458 "Hook method for deconstructing the test fixture after testing 
it."
(Pdb) n
> /data/prj/python/git/x067-python3-3.7/Lib/unittest/case.py(455)setUp()
-> pass
(Pdb) n
--Return--
> /data/prj/python/git/x067-python3-3.7/Lib/unittest/case.py(455)setUp()->None
-> pass
(Pdb) n
--Return--
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2189)setUp()->None
-> super().setUp()
(Pdb) l
2184# None for no timeout.  Not all tests actually set a timeout.
2185fail_timeout = 3.0
2186
2187def setUp(self):
2188self.misc_event = threading.Event()
2189 -> super().setUp()
2190
2191def sendToServer(self, msg):
2192# Send msg to the server.
2193return self.cli_sock.send(msg)
2194
(Pdb) s
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_s

[issue11192] test_socket error on AIX

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Back to master (python3-3.7)

(note: not your problem - but this link is gone: not a python problem, see 
closed aix issue http://www-01.ibm.com/support/docview.wss?uid=isg1IZ57712)

Getting this (obviously) on AIX 5.3, but also on AIX 6.1 (TL6), but not on AIX 
7.1 TL2: (both gcc and xlc)

testGetSockOpt (test.test_socket.GeneralModuleTests) ... ok
testGetaddrinfo (test.test_socket.GeneralModuleTests) ... FAIL
testHostnameRes (test.test_socket.GeneralModuleTests) ... ok

However, what I get on all three systems (but do not see on the AIX buildbot 
running on AIX 7.2, and I have no access to AIX 7.2) is:

AIX 6.1:
Ran 669 tests in 25.899s

FAILED (failures=1, errors=114, skipped=119)

AIX 7.1:

Ran 669 tests in 25.917s

FAILED (errors=114, skipped=119)

What all the ERRORS have in common is:

  File "/data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py", line 
2373, in setUp
self.serv_sock.settimeout(self.fail_timeout)
AttributeError: 'SendmsgTests' object has no attribute 'serv_sock'

HTH - (and still digging)

--
versions: +Python 3.7 -Python 2.7, Python 3.2

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue11192>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11191] test_search_cpp error on AIX (with xlc)

[Michael Felt]

Change by Michael Felt <mich...@felt.demon.nl>:


--
keywords: +patch
pull_requests: +5060
stage:  -> patch review

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue11191>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11191] test_search_cpp error on AIX (with xlc)

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

a) Is this normal?

root@x065:[/data/prj/python/git/python3-3.7]./python -m unittest 
test.test_distutils

--
Ran 0 tests in 0.000s

OK

In short - at the start I had:

./python Lib/test/test_distutils.py 
...
ERROR: test_run (distutils.tests.test_build_clib.BuildCLibTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_get_outputs 
(distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)

That is now down to:
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)

There were two issues for search_cpp:
a) xlc -E needs -C to include comments in the output - this should be fixed
b) xlc -E does not accept -o as an argument - output must be to stdout, and 
sadly I am not clever enough to fix that. Help appreciated.

As is: the error was:

ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
--
Traceback (most recent call last):
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/unixccompiler.py", 
line 107, in preprocess
self.spawn(pp_args)
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/ccompiler.py", line 
909, in spawn
spawn(cmd, dry_run=self.dry_run)
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/spawn.py", line 36, 
in spawn
_spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/spawn.py", line 159, 
in _spawn_posix
% (cmd, exit_status))
distutils.errors.DistutilsExecError: command 'xlc_r' failed with exit status 40

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/data/prj/python/git/xlc-python3-3.7/Lib/distutils/tests/test_config_cmd.py", 
line 49, in test_search_cpp
match = cmd.search_cpp(pattern='xxx', body='/* xxx */')
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/command/config.py", 
line 201, in search_cpp
src, out = self._preprocess(body, headers, include_dirs, lang)
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/command/config.py", 
line 124, in _preprocess
self.compiler.preprocess(src, out, include_dirs=include_dirs)
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/unixccompiler.py", 
line 109, in preprocess
raise CompileError(msg)
distutils.errors.CompileError: command 'xlc_r' failed with exit status 40

and it is now:
==
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
--
Traceback (most recent call last):
  File 
"/data/prj/python/git/python3-3.7/Lib/distutils/tests/test_config_cmd.py", line 
49, in test_search_cpp
match = cmd.search_cpp(pattern='xxx', body='/* xxx */')
  File "/data/prj/python/git/python3-3.7/Lib/distutils/command/config.py", line 
206, in search_cpp
file = open(out)
FileNotFoundError: [Errno 2] No such file or directory: '_configtest.i'

*
The code I do not know how to fix is:

File: Lib/distutils/command/config.py
def _preprocess(self, body, headers, include_dirs, lang):
src = self._gen_temp_sourcefile(body, headers, lang)
out = "_configtest.i"
self.temp_files.extend([src, out])
self.compiler.preprocess(src, out, include_dirs=include_dirs)
return (src, out)

See https://github.com/aixtools/cpython/tree/bpo-11191 for my changes

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue11191>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11191] test_search_cpp error on AIX (with xlc)

[Michael Felt]

Change by Michael Felt <mich...@felt.demon.nl>:


--
versions: +Python 3.7 -Python 3.2

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue11191>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11191] test_search_cpp error on AIX (with xlc)

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

After even more years - I see the same test failing, just a bit different.

And, others

in short:

./python Lib/test/test_distutils.py
...
Ran 245 tests in 10.337s

FAILED (errors=7, skipped=31)

I have managed to get this to:

FAILED (errors=1, skipped=37)

And this is still:

ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)

So, moving forward now.

--
nosy: +Michael.Felt

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue11191>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 14/01/2018 22:01, Antoine Pitrou wrote:
> Antoine Pitrou <pit...@free.fr> added the comment:
>
> Is nohup required in the example you just posted or is that a red herring?
>
> --
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue28009>
> ___
>
nohup is required (i.e., my lazy way!) to stream both stdout and stderr 
through the pipe. Perhaps, for this output nohup could have been 
omitted. But it became a habit while I was testing. Maybe a birthday 
herring :p

Working on the Windows issue (my mistake). Will be groping in the dark 
as I have no windows system to test on.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28009>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32542] memory not freed, aka memory leak continues...

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Thanks for the clarification. 

Being curious, is there a way to see what the size of the cache is? I want to 
believe, but i do not have the impression memory is being reallocated to later 
users. My gut feeling is that the code change permits repeated calls to a 
function in a way that it reuses memory it received before (rather than a 
memory leak of repeatedly allocating a brand new buffer). What I expected, more 
accurately hoped for, is that cache was either freed and/or made available for 
reuse. 

Since I am on my phone atm I am less successful at finding documentation. I 
would be very grateful for a link to the relevant information and I’ll look 
further, time permitting. Thx again,

Michael 

Sent from my iPhone

> On 12 Jan 2018, at 23:48, Serhiy Storchaka <rep...@bugs.python.org> wrote:
> 
> 
> Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment:
> 
> Issue25582 fixed a memory leak. If run the tests repeatedly every iteration 
> leaked 100 MB of memory. If you get a MemoryError with a single iteration, 
> this means that your machine just doesn't have enough memory for tests. Tests 
> require around 500-600MB of memory on 32-bit platform.
> 
> --
> nosy: +serhiy.storchaka
> 
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue32542>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32542>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

FYI: - On AIX, no uuid_create support:

./python -m unittest -v test.test_uuid
...
Ran 48 tests in 0.261s

OK (skipped=37)

On AIX 6.1 (with ctypes, without _uuid)

./python -m unittest -v test.test_uuid
...
Ran 48 tests in 0.274s

OK (skipped=32)

On AIX 6.1 (with ctypes, with _uuid)

./python -m unittest -v test.test_uuid
...
Ran 48 tests in 0.379s

OK (skipped=16)

+++

nohup ./python -m unittest -v test.test_uuid | grep skipped
test_arp_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 'AIX 
arp does not provide MAC addr'
test_ifconfig_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'AIX ifconfig does not provide MAC addr'
test_ip_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires ip'
test_ipconfig_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires Windows'
test_lanscan_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires lanscan'
test_netbios_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires win32wnet'
test_windll_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires Windows'
test_arp_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'AIX arp does not provide MAC addr'
test_ifconfig_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... 
skipped 'AIX ifconfig does not provide MAC addr'
test_ip_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires ip'
test_ipconfig_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... 
skipped 'requires Windows'
test_lanscan_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires lanscan'
test_netbios_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires win32wnet'
test_windll_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires Windows'
test_uuid1_safe (test.test_uuid.TestUUIDWithExtModule) ... skipped 'requires 
uuid_generate_time_safe(3)'
test_uuid1_safe (test.test_uuid.TestUUIDWithoutExtModule) ... skipped 'requires 
uuid_generate_time_safe(3)'

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28009>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

PR added, please review.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28009>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Change by Michael Felt <mich...@felt.demon.nl>:


--
keywords: +patch
pull_requests: +5037
stage:  -> patch review

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28009>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32542] memory not freed, aka memory leak continues...

[Michael Felt]

New submission from Michael Felt <mich...@felt.demon.nl>:

in issue25582 - the issue is not (yet) resolved. Perhaps this one can be closed 
and issue25582 reopened.

Both from python2-2.7.14 and "git master" I am getting:

michael@x071:[/data/prj/python/git/gcc-python3-3.7]./python -m unittest -v 
ctypes.test.test_pointers  <
test_abstract (ctypes.test.test_pointers.PointersTestCase) ... ok
test_basic (ctypes.test.test_pointers.PointersTestCase) ... ok
test_basics (ctypes.test.test_pointers.PointersTestCase) ... ok
test_bug_1467852 (ctypes.test.test_pointers.PointersTestCase) ... ok
test_c_void_p (ctypes.test.test_pointers.PointersTestCase) ... ok
test_callbacks_with_pointers (ctypes.test.test_pointers.PointersTestCase) ... ok
test_change_pointers (ctypes.test.test_pointers.PointersTestCase) ... ok
test_charpp (ctypes.test.test_pointers.PointersTestCase)
Test that a character pointer-to-pointer is correctly passed ... ok
test_from_address (ctypes.test.test_pointers.PointersTestCase) ... ok
test_other (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pass_pointers (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pointer_crash (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pointer_type_name (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pointer_type_str_name (ctypes.test.test_pointers.PointersTestCase) ... 
ERROR
test_pointers_bool (ctypes.test.test_pointers.PointersTestCase) ... ok

==
ERROR: test_pointer_type_str_name (ctypes.test.test_pointers.PointersTestCase)
--
Traceback (most recent call last):
  File "/data/prj/python/git/gcc-python3-3.7/Lib/ctypes/test/test_pointers.py", 
line 208, in test_pointer_type_str_name
large_string = 'T' * 2 ** 25
MemoryError

--
Ran 15 tests in 0.319s

FAILED (errors=1)

+
Looking at the test source:

  +196  def test_pointer_type_name(self):
  +197  LargeNamedType = type('T' * 2 ** 25, (Structure,), {})
  +198  self.assertTrue(POINTER(LargeNamedType))
  +199
  +200  # to not leak references, we must clean _pointer_type_cache
  +201  from ctypes import _pointer_type_cache
  +202  del _pointer_type_cache[LargeNamedType]
  +203
  +204  def test_pointer_type_str_name(self):
  +205  large_string = 'T' * 2 ** 25
  +206  P = POINTER(large_string)
  +207  self.assertTrue(P)
  +208
  +209  # to not leak references, we must clean _pointer_type_cache
  +210  from ctypes import _pointer_type_cache
  +211  del _pointer_type_cache[id(P)]


After changing the exponent (** 25) to "** 23" on either line 197 OR 205 
- ALL test succeed -
After changing the exponent to " ** 24" on BOTH lines 197 and 205, all tests 
pass.


My concern is that the "patch" from issue 25582 the 
"del _pointer_type_cache[]" statement is not freeing memory.

+
What can I add to the test to debug!
+
p.s. - results are the same on AIX (5.3 and 6.1) Python2-2.7.14 and 
Pyhton3-3.7.X (git master). Compiler does not seem to matter (both xlc and gcc).
32-bit, default memory model (256 MByte max - aka (2 ** 28) for data and 
malloc. I could also try changing the memory model - but will do that only if 
the test, by definition, is not "free()ing" the memory used, when done.

HTH
Michael

--
components: Tests
messages: 309869
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: memory not freed, aka memory leak continues...
type: behavior
versions: Python 2.7, Python 3.7

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32542>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

@panter - your patch seems to be working well. Thanks.

PR 5164 submitted for review

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27643>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Change by Michael Felt <mich...@felt.demon.nl>:


--
pull_requests: +5020

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27643>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 04/08/2016 10:58, Martin Panter wrote:
> Martin Panter added the comment:
>
> Okay, so to be clear, I am assuming XLC supports all of the following fields, 
> and uses unsigned bit fields by default:
>
> struct UNSIGNED_BITS {
>  unsigned int AU: 1;
>  int A: 1; /* Equivalent to unsigned int */
>  signed int AS: 1;
>  unsigned short MU: 1;
>  short M: 1; /* Equivalent to unsigned short; triggers warning */
> };
>
> and that it cannot compile the following:
>
> struct SIGNED_BITS {
>  signed short MS: 1; /* Not supported */
> };
>
> Attached is what I think a patch to resolve this would look like. However it 
> needs a line in Modules/_ctypes/_ctypes_test.c completed to detect the 
> compiler:
>
> #ifndef /* Something to identify XLC */
>
> Can you figure out a way to test for XLC (but not GCC, which the AIX buildbot 
> uses),

I'll figure this out. HOWEVER, Just want to mention that both parts of 
C_Test are failing when using xlc (i.e., on "A" and "M"). Note line 40 
and 51.

(Have not done the compiler detect part yet, so it still returns 
something != 999)

    +33  class C_Test(unittest.TestCase):
    +34
    +35  def test_ints(self):
    +36  for i in range(512):
    +37  for name in "ABCDEFGHI":
    +38  b = BITS()
    +39  setattr(b, name, i)
    +40  self.assertEqual(getattr(b, name), 
func(byref(b), name.encode('ascii')))
    +41
    +42  def test_shorts(self):
    +43  b = BITS()
    +44  name = "M"
    +45  if func(byref(b), name.encode('ascii')) == 999:
    +46  self.skipTest("Compiler does not support signed 
short bitfields")
    +47  for i in range(256):
    +48  for name in "MNOPQRS":
    +49  b = BITS()
    +50  setattr(b, name, i)
    +51  self.assertEqual(getattr(b, name), 
func(byref(b), name.encode('ascii')))
    +52

==
FAIL: test_ints (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
   File 
"/data/prj/python/git/xlc-python3-3.7/Lib/ctypes/test/test_bitfields.py", 
line 40, in test_ints
     self.assertEqual(getattr(b, name), func(byref(b), 
name.encode('ascii')))
AssertionError: -1 != 1

==
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
   File 
"/data/prj/python/git/xlc-python3-3.7/Lib/ctypes/test/test_bitfields.py", 
line 51, in test_shorts
     self.assertEqual(getattr(b, name), func(byref(b), 
name.encode('ascii')))
AssertionError: -1 != 1

--

> and then try my patch out? Hopefully you see no more compiler warnings, 
> test_ints() should now pass,
again - not done the changes to _ctypes_test.c yet - so maybe the 
test_ints() will pass after that.
>   and test_shorts() should be skipped.
>
> --
> keywords: +patch
> Added file: http://bugs.python.org/file44005/disable-signed-short.patch
>
> ___
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue27643>
> ___

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27643>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 30/07/2016 02:51, Martin Panter wrote:
> Martin Panter added the comment:
>
>
> ./python -m unittest -v ctypes.test.test_bitfields
>
> What I am suggesting as a fix is to change line 381 from plain “int” to 
> “signed int”, and 382 to “signed short”.

As some time has passed, I assume you mean look at this change:

struct BITS {
 signed int A: 1, B:2, C:3, D:4, E: 5, F: 6, G: 7, H: 8, I: 9;
 signed short M: 1, N: 2, O: 3, P: 4, Q: 5, R: 6, S: 7;
};

> I can make a patch later if that will help. Hopefully with these changes the 
> C compiler will use signed integer logic, matching what I believe the ctypes 
> library uses for c_int and c_short.

Not helping the compilation in any case - same messages as before.

* Default make:

michael@x071:[/data/prj/python/git/xlc-python3-3.7]xlc_r -DNDEBUG -O 
-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/>
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for M is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for N is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for O is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for P is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for Q is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for R is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for S is not valid. 
Type unsigned assumed.

* Adding (manually) -qbitfields=signed - almost the same.

michael@x071:[/data/prj/python/git/xlc-python3-3.7]xlc_r 
-qbitfields=signed -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 >
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for M is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for N is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for O is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for P is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for Q is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for R is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for S is not valid. 
Type signed assumed.

> Using a type other than short is not right, because the Python test is 
> explicitly trying to test c_short behaviour. If your compiler does not 
> support “signed short” bitfields, maybe we just have to accept that ctypes 
> supports it even though the compiler doesn’t, and skip the test.
Shall reply, asap, to your suggestion for a test that knows the 
difference in compilers.
>
> --
>
> ___
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue27643>
> ___

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27643>
___
___
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 <mich...@felt.demon.nl>:


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

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27435>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 09/01/2018 16:21, Antoine Pitrou wrote:
> Antoine Pitrou <pit...@free.fr> added the comment:
>
>> What is the desired behavior, specifically, of
> uuid.getnode() - constant, or 'random'?
>
> I'm also certain getnode() is supposed to return a hardware-determined number 
> (usually the MAC address of an Ethernet interface).  A random output wouldn't 
> need so much platform-specific harness.

FYI

The current implementation (Lib/uuid.py) - python2 as an example with 
with no _uuid support, compared to the master (as of yesterday) with 
_uuid support.

Program (x2.py):

michael@x071:[/data/prj/python/git]cat *master/x2.py
import uuid
import sys
print (sys.version)
print("getnode = %x\n" % uuid.getnode())
print("getnode = %x\n" % uuid.getnode())

michael@x071:[/data/prj/python/git]python *master/x2.py
2.7.12 (default, Sep 29 2016, 12:02:17) [C]
getnode = a92929dc8a78

getnode = a92929dc8a78

michael@x071:[/data/prj/python/git]python *master/x2.py
2.7.12 (default, Sep 29 2016, 12:02:17) [C]
getnode = cdff09dd1306

getnode = cdff09dd1306

So it appears, everytime python runs - without _uuid - a new "getnode()" 
value is established, for as long as the process runs (hoping!)

Below - the value returned is the MAC address of the first ethernet 
adapter (ent0)

michael@x071:[/data/prj/python/git]gcc*/python *master/x2.py
3.7.0a3+ (default, Jan  8 2018, 16:05:08)
[GCC 4.7.4]
getnode = fad18cf76204

getnode = fad18cf76204

michael@x071:[/data/prj/python/git]xlc*/python *master/x2.py
3.7.0a3+ (heads/master:9b99747, Jan  8 2018, 15:50:03) [C]
getnode = fad18cf76204

getnode = fad18cf76204

*

Is there any interest for a PR on Python2.7 and/or Python3.5? I guess it 
could be considered a bug IF the getnode() value is suppossed to be 
related to the MAC address and/or consistent over sessions.

HTH, Michael

>
> --
> nosy: +pitrou
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue28009>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28009>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 08/01/2018 17:22, Michael wrote:
> On 08/01/2018 16:07, Michael Felt wrote:
>> Michael Felt <mich...@felt.demon.nl> added the comment:
>>
>> Considering that _uuid is now working for AIX issue32399 -

some time differences - this is on POWER6 (10 years old system) - I 
expect POWER8 and POWER9 to be much quicker in exact times.

michael@x071:[/data/prj/python/git/xlc-python3-3.7]./python
Python 3.7.0a3+ (heads/master:9b99747, Jan  8 2018, 15:50:03) [C] on aix6
Type "help", "copyright", "credits" or "license" for more information.
 >>>
michael@x071:[/data/prj/python/git/xlc-python3-3.7]./python -m timeit -n 
100 -r 5 'import uuid; getnode = uuid.getnode()'
100 loops, best of 5: 911 nsec per loop

michael@x071:[/data/prj/python/git/xlc-python3-3.7]python
Python 2.7.12 (default, Sep 29 2016, 12:02:17) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
 >>>
michael@x071:[/data/prj/python/git/xlc-python3-3.7]python -m timeit -n 
100 -r 5 'import uuid; getnode = uuid.getnode()'
100 loops, best of 5: 2.86 usec per loop
michael@x071:[/data/prj/python/git/xlc-python3-3.7]

The second example is a) before the _uuid support was in the code, and 
b) even if in the code would not have been built on AIX5.

The relative difference is: 911/2860 :: 31.85/100 - or roughly 3x faster 
with _uuid.

As far as this issue is concerned - with _uuid active the buggy code I 
mentioned for getnode() is defunct as it does not get called/parsed. 
However, I shall continue with it.

Question: (must have questions!) - the behavior of getnode() without 
_uuid is a 'random' value for getnode() with my current setup BUT using 
the _uuid module it is a 'constant' that is related to (one of) the 
network interface(s). What is the desired behavior, specifically, of 
uuid.getnode() - constant, or 'random'?

>>
>> Does uuid.py (./Lib/uuid.py) call _uuid.py?

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28009>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 08/01/2018 16:07, Michael Felt wrote:
> Michael Felt <mich...@felt.demon.nl> added the comment:
>
> Considering that _uuid is now working for AIX issue32399 - I need to get some 
> things straight (aka some help please).
>
> Does uuid.py (./Lib/uuid.py) call _uuid.py?
>
> If not, I am curious how _uuid.c is used - because ./Lib/test/test_uuid.py 
> does not seem to be successful in finding it:
>
>> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(10)()
> -> py_uuid = support.import_fresh_module('uuid', blocked=['_uuid'])
> (Pdb) n
>> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(11)()
> -> c_uuid = support.import_fresh_module('uuid', fresh=['_uuid'])
> (Pdb) n
>> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(14)()
> -> def importable(name):
> (Pdb) py_uuid
> 
> (Pdb) c_uuid
> (Pdb)
>
> So, for now it seems the test is only testing 'uuid.py'. I would like to see 
> the added value of having gotten the _uuid Module to build.
>
> However, if this is 'working as designed' I not worry about it and just go 
> back into the util.py - getnode() etc.

Got this figured out. tested on too many machines - the last version 
built was on AIX5 - which does not have uuid() functions in libc.a.

Running on AIX6 - I get:

(Pdb) py_uuid

(Pdb) c_uuid

(Pdb) import _uuid
(Pdb) _uuid

(Pdb)

However, have a new question - why are py_uuid and c_uuid 'equivalent'. 
(_uuid is shown just to show that it can be imported).

A comment - perhaps a new bpo/issue topic. When trying to run the tests 
from a freshly built version - it still seems to default to looking at 
the installed version first. And that can make debugging very very hard 
(which modules are actually getting loaded?!). In this case, there also 
seem to be a python2 and python3 incompatibility - notice the python2.7 
pdb reference!

michael@x071:[/data/prj/python/git/python3-master]python -m pdb 
./Lib/test/test_uuid.py
Traceback (most recent call last):
   File "/opt/lib/python2.7/pdb.py", line 1314, in main
     pdb._runscript(mainpyfile)
   File "/opt/lib/python2.7/pdb.py", line 1233, in _runscript
     self.run(statement)
   File "/opt/lib/python2.7/bdb.py", line 400, in run
     exec cmd in globals, locals
   File "", line 1, in 
   File "./Lib/test/test_uuid.py", line 520
     print(hex, end=' ')

>
> --
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue28009>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28009>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Considering that _uuid is now working for AIX issue32399 - I need to get some 
things straight (aka some help please).

Does uuid.py (./Lib/uuid.py) call _uuid.py?

If not, I am curious how _uuid.c is used - because ./Lib/test/test_uuid.py does 
not seem to be successful in finding it:

> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(10)()
-> py_uuid = support.import_fresh_module('uuid', blocked=['_uuid'])
(Pdb) n
> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(11)()
-> c_uuid = support.import_fresh_module('uuid', fresh=['_uuid'])
(Pdb) n
> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(14)()
-> def importable(name):
(Pdb) py_uuid

(Pdb) c_uuid
(Pdb)

So, for now it seems the test is only testing 'uuid.py'. I would like to see 
the added value of having gotten the _uuid Module to build.

However, if this is 'working as designed' I not worry about it and just go back 
into the util.py - getnode() etc.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28009>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 08/01/2018 12:47, David Carlier wrote:
> David Carlier <dcarl...@afilias.info> added the comment:
>
> Perfect. That solves in the process OpenBSD uuid module build too.
>
> --
p.s. I did not 'invent' unsigned32 - just took the syntax from the man 
page: 
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.basetrf2/uuid_create.htm
 
- and I just did the grep above to show the type existed AND was 
directly related to unsigned32 - even in AIX include files.
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue32493>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32493>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 05/01/2018 13:38, Antoine Pitrou wrote:
> Antoine Pitrou <pit...@free.fr> added the comment:
>
> Michael, does AIX have uint32_t?  If so, we could happily drop the unsigned32 
> reference.

Yes, AIX has unit32_t.

michael@x071:[/home/michael]grep unsigned32 /usr/include/*.h 
/usr/include/sys/*.h | grep typed
/usr/include/uuid.h:typedef u_int32_t unsigned32;  /* positive 32 
bit integer */
/usr/include/uuid.h:typedef unsigned32 boolean32;

>
> --
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue32493>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32493>
___
___
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 <mich...@felt.demon.nl> 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 <rep...@bugs.python.org>
> <http://bugs.python.org/issue27435>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27435>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32390] AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 03/01/2018 18:03, Xavier de Gaye wrote:
> Xavier de Gaye <xdeg...@gmail.com> added the comment:
>
> The following patch may be less invasive and more explicit:
>
> diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
> index 38b6c80e6b..e0bb4ba869 100644
> --- a/Modules/posixmodule.c
> +++ b/Modules/posixmodule.c
> @@ -9325,7 +9325,11 @@ _pystatvfs_fromstructstatvfs(struct statvfs st) {
>   PyStructSequence_SET_ITEM(v, 8, PyLong_FromLong((long) st.f_flag));
>   PyStructSequence_SET_ITEM(v, 9, PyLong_FromLong((long) st.f_namemax));
>   #endif
> +#if defined(_AIX) && defined(_ALL_SOURCE)
> +PyStructSequence_SET_ITEM(v, 10, 
> PyLong_FromUnsignedLong(st.f_fsid.val[0]));
> +#else
>   PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong(st.f_fsid));
> +#endif
>   if (PyErr_Occurred()) {
>   Py_DECREF(v);
>   return NULL;
>
> --
Applied to the PR. Thx.
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue32390>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32390] AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Ignore my last comment - I have a headache. If I could edit/delete it I would.

aka "reset 2018 - here I come!"

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32390] AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 03/01/2018 14:41, David Edelsohn wrote:
> David Edelsohn <dje@gmail.com> added the comment:
>
> _ALL_SOURCE is overkill. It probably is too big a club for this regression.

Maybe. Clearly it is a big club. The documentation - if you can find any 
- is ancient and/or confusing. For example the xlc compiler reference 
quide (v12 is what I referenced, not the latest, but what I found) only 
has a single reference to any "_SOURCE" macro (-D_POSIX_SOURCE).

I do not know 'why' AIX and Linux differ in the way they name things. I 
do not want to care either - which is why I, personally, am less 
concerned about the size of the club. People much more clever than I 
decided that many variable names should be without two underscores 
(_ALL_SOURCE is defined) while others felt they must have two 
underscores (_ALL_SOURCE is undefined).

IMHO: 15+ years ago IBM (AIX) worked to find a method to simplify 
porting. And, I hope somewhere someone knows what these all meant. The 
practice seems to be to always define _ALL_SOURCE (see configure.ac:
   +882  # checks for UNIX variants that set C preprocessor variables
   +883  AC_USE_SYSTEM_EXTENSIONS
   +884
https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Posix-Variants.html

Here is where I read that _ALL_SOURCE is for AIX3. I can neither deny 
nor affirm that that is (still) accurate. But that is what working with 
autotools does. Throws a sauce over everything that may, or maynot be 
what is needed.

I considered it 'interesting' that  at least talks a bit 
about _POSIX_SOURCE and _ALL_SOURCE.

>   However, the AIX header definition of fsid compatible with the current 
> Python posixmodule.c code is bracketed by _ALL_SOURCE.
>
> AFAICT, the change to posixmodule.c made assumptions about fsid based on 
> Linux and not required by POSIX. This didn't simply introduce a testsuite 
> regression, but broke the build on AIX. The posixmodule.c code should be 
> corrected or should be reverted.

Maybe reverting the change is better than using the "big club". But, 
asis, AIX is dead to development. Was it possible to have AIX included 
in the PR test process I would hope that the PR would never have been 
merged.

IMHO - this is a spelling issue, going back years. But if you use a 
UK-only spelling checker and try and use only US spelling rules - and 
v.v. - there will be 'issues'. What is the solution with the most 
clarity? Above my pay grade to answer.

In any case the previous issue that saw adding fsid as a solution was 
not fully tested across all platforms. Currently AIX is broken. Someone 
needs to decide how to restore a supported platform - and where the 
discussion on fsid either restarts or continues.

In short - I am just a messenger - you are the experts. :)

>
> --
> nosy: +vstinner
> title: AIX (xlc_r) compile error with Modules/posixmodule.c: Function 
> argument assignment between types "unsigned long" and "struct fsid_t" is not 
> allowed -> AIX compile error with Modules/posixmodule.c: Function argument 
> assignment between types "unsigned long" and "struct fsid_t" is not allowed
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue32390>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27632] build on AIX fails when builddir != srcdir, more than bad path to ld_so_aix

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

There were changes made - I know not when - but OOT builds work now. This issue 
may be closed.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27632>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28290] BETA report: Python-3.6 build messages to stderr: AIX and "not GCC"

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

this was just feedback - and should probably be closed.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28290>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

As I was not responding properly (too verbose) - I'll reread the thread for the 
initial patch suggestion - and hope it still fits the current 'master'.

My apologies for the long silence on this.

--
nosy:  -aixto...@gmail.com

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27643>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Did some additional research. The code can work asis when _ALL_SOURCE is 
undefined. Or, in other words - there does not have to be a variable syntax 
issue or separate code for AIX.

As you read this - please remember that since issue #32143 was 'resolved' AIX 
cannot compile.

* 
https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Posix-Variants.html

describes _ALL_SOURCE as a macro for AIX3.

Looking at AIX: /usr/include/sys/types.h - by undefining _ALL_SOURCE the 
typedefs in the header files are equivalent enough that the new code added for 
os.statvfs(path) is compiled by both gcc and xlc.

As examples (from Centos)
/usr/include/bits/typesizes.h:72:#define __FSID_T_TYPE  struct { int 
__val[2]; }

And from AIX:
 * /usr/include/sys/types.h
  +360  / * typedef for the File System Identifier (fsid).  This must correspond
  +361* to the "struct fsid" structure in _ALL_SOURCE below.
  +362* /
  +363  typedef struct fsid_t {
  +364  #ifdef __64BIT_KERNEL
  +365  unsigned long val[2];
  +366  #else  / * __64BIT_KERNEL * /
  +367  #ifdef _ALL_SOURCE
  +368  unsigned int val[2];
  +369  #else  / * _ALL_SOURCE * /
  +370  unsigned int __val[2];
  +371  #endif / * _ALL_SOURCE * /
  +372  #endif / * __64BIT_KERNEL * /
  +373  } fsid_t;
 */

(Note - a variation of the text above was in the pull request 
https://github.com/python/cpython/pull/4972. Per reviewer request - this is 
removed and a discussion is now open here.)

Thank you for your comments.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

will open a new PR for ./Doc/library/ctypes.rst

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue26439>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc..

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

As the 'basics' seem to be 'accepted', going to work on the PR so that 
configure.ac can prepare the right choices, rather than rely on a hard-coded 
_AIX determined macro.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32399>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc..

[Michael Felt]

Change by Michael Felt <mich...@felt.demon.nl>:


--
keywords: +patch
pull_requests: +4865
stage:  -> patch review

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32399>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Michael Felt]

Change by Michael Felt <mich...@felt.demon.nl>:


--
keywords: +patch
pull_requests: +4863
stage:  -> patch review

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Well, replied via email response - but it did not show up here.

You suggestion worked. I'll start a PR and we can see if your suggestion also 
works for all the other platforms.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc..

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Understood.

What I have learned.

Although the types are quite different, they are both 16 bytes.

Starting with AIX 6.1, libc includes uuid_create(, )
which fills "uuid" with a uuid.uuid1() like result.
After calling uuid_to_string( , _string, ); the result:
"13d866fa-e6f1-11e7-8017-fad18cf76204"

Further reading of the documentation within """ and """ in Lib/uuid.py helps me 
realize that the AIX approach aligns with the UUID fields description:

fields  a tuple of the six integer fields of the UUID,
which are also available as six individual attributes
and two derived attributes:

time_lowthe first 32 bits of the UUID
time_midthe next 16 bits of the UUID
time_hi_version the next 16 bits of the UUID
clock_seq_hi_variantthe next 8 bits of the UUID
clock_seq_low   the next 8 bits of the UUID
nodethe last 48 bits of the UUID


So - with this: there is also more than can be done for AIX re: 
https://bugs.python.org/issue28009

More to come...

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32399>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc..

[Michael Felt]

Change by Michael Felt <mich...@felt.demon.nl>:


--
type:  -> behavior

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32399>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc..

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

So - KISS principle:

This diff shows what can compile:

diff --git a/Modules/_uuidmodule.c b/Modules/_uuidmodule.c
index d4bc3c7..5550705 100644
--- a/Modules/_uuidmodule.c
+++ b/Modules/_uuidmodule.c
@@ -1,7 +1,11 @@
 #define PY_SSIZE_T_CLEAN

 #include "Python.h"
+#ifndef _AIX
 #include 
+#else
+#include 
+#endif


 static PyObject *
@@ -16,7 +20,11 @@ py_uuid_generate_time_safe(void)
 #else
 uuid_t out;
 uuid_generate_time(out);
+#ifndef _AIX
 return Py_BuildValue("y#O", (const char *) out, sizeof(out), Py_None);
+#else
+return Py_BuildValue("y#O", (const char *) , sizeof(out), Py_None);
+#endif
 #endif
 }

However, no uuid_generate_time(). So, ends with:
ld: 0711-317 ERROR: Undefined symbol: .uuid_generate_time

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32399>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc..

[Michael Felt]

New submission from Michael Felt <mich...@felt.demon.nl>:

I was hoping for something simple - as in:

+1  #define PY_SSIZE_T_CLEAN
+2
+3  #include "Python.h"
+4  #ifndef _AIX
+5  #include 
+6  #else
+7  #include 
+8  #endif

However, it dies - instantly.

   11 | static PyObject *
   12 | py_uuid_generate_time_safe(void)
   13 | {
   14 | #ifdef HAVE_UUID_GENERATE_TIME_SAFE
   15 | uuid_t out;
   16 | int res;
   17 |
   18 | res = uuid_generate_time_safe(out);
   19 | return Py_BuildValue("y#i", (const char *) out, sizeof(out), 
res);
   20 | #else
   21 | uuid_t out;
   22 | uuid_generate_time(out);
   23 | return Py_BuildValue("y#O", (const char *) out, sizeof(out), 
Py_None);
   23 + return _Py_BuildValue_SizeT("y#O", (const char *) out, 
sizeof(out), (&_Py_NoneStruct));
"/data/prj/python/git/python3-3.7.0.a3/Modules/_uuidmodule.c", line 23.48: 
1506-117 (S) Operand must be a scalar type.
   24 | #endif
   25 | }
   26 |

On a linux system I see:

typedef unsigned char uuid_t[16];

while on AIX the typedef is:

/*
 * Universal Unique Identifier (UUID) types.
 */
typedef struct _uuid_t
{
unsigned32  time_low;
unsigned16  time_mid;
unsigned16  time_hi_and_version;
unsigned8   clock_seq_hi_and_reserved;
unsigned8   clock_seq_low;
byte   node[6];
} uuid_t, *uuid_p_t;

So, mentioning this for now - as I do not yet know the module. If someone with 
intimate knowledge of the current implementation is willing to help me - I'll 
dabble and learn - and see if we can make it work on AIX as well.

p.s. - guessing on the "Extension Modules" label. If not the right choice, 
please update.

--
components: Extension Modules
messages: 308894
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc..
versions: Python 3.7

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32399>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

Sure - I'll work on a PR. This will be the easier one.

Where I am currently 'lost' is to correct _uuidmodule.c - another thing that 
has always been broken (new issue, about to open).

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28009>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

FYI: from /usr/include/types.h

/* typedef for the File System Identifier (fsid).  This must correspond
 * to the "struct fsid" structure in _ALL_SOURCE below.
 */
typedef struct fsid_t {
#ifdef __64BIT_KERNEL
unsigned long val[2];
#else  /* __64BIT_KERNEL */
#ifdef _ALL_SOURCE
unsigned int val[2];
#else  /* _ALL_SOURCE */
unsigned int __val[2];
#endif /* _ALL_SOURCE */
#endif /* __64BIT_KERNEL */
} fsid_t;

And, currently I am building in 32-bit mode, with a 64BIT kernel (AIX 6.1) - so 
I expect it to be 2 unsigned_longs.

However, I am not smart enough to find a solution: I tried:
PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong((unsigned long) 
st.f_fsid));

and PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong((unsigned long 
*) st.f_fsid));

Both return:

"./Modules/posixmodule.c", line 9328.80: 1506-117 (S) Operand must be a scalar 
type.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

OOps - wrong error! 

It is the new fsid variable!

michael@x071:[/data/prj/python/git/python3-3.7.0.a3]xlc_r  -DNDEBUG -O 
-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5  -I. -I./Include -I/opt/in>
"./Modules/posixmodule.c", line 5514.11: 1506-131 (W) Explicit dimension 
specification or initializer required for an auto or static array.
"./Modules/posixmodule.c", line 9328.64: 1506-280 (S) Function argument 
assignment between types "unsigned long" and "struct fsid_t" is not allowed.

 9326 | PyStructSequence_SET_ITEM(v, 9, PyLong_FromLong((long) 
st.f_namemax));
 9326 + (((PyTupleObject *)(v))->ob_item[9] = PyLong_FromLong((long) 
st.f_namemax));
 9327 | #endif
"./Modules/posixmodule.c", line 9328.64: 1506-280 (S) Function argument 
assignment between types "unsigned long" and "struct fsid_t" is not allowed
.
 9328 | PyStructSequence_SET_ITEM(v, 10, 
PyLong_FromUnsignedLong(st.f_fsid));
 9328 + (((PyTupleObject *)(v))->ob_item[10] = 
PyLong_FromUnsignedLong(st.f_fsid));
 9329 | if (PyErr_Occurred()) {
 9330 | Py_DECREF(v);
 9330 + do { PyObject *_py_decref_tmp = (PyObject *)(v); if (   
--(_py_decref_tmp)->ob_refcnt != 0) ; else (  (*(((PyObject*)(_py_d
ecref_tmp))->ob_type)->tp_dealloc)((PyObject *)(_py_decref_tmp))); } while (0);

--
title: AIX (xlc_r) compile error with Modules/posixmodule.c: Explicit dimension 
specification or initializer required -> AIX (xlc_r) compile error with 
Modules/posixmodule.c: Function argument assignment between types "unsigned 
long" and "struct fsid_t" is not allowed

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Explicit dimension specification or initializer required

[Michael Felt]

New submission from Michael Felt <mich...@felt.demon.nl>:

current level: commit 4b965930e8625f77cb0e821daf5cc40e85b45f84 (HEAD -> master, 
upstream/master, origin/master, origin/HEAD)

Build message:
michael@x071:[/data/prj/python/git/python3-3.7.X]make
xlc_r  -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5  -I. 
-I./Include -I/opt/include   -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o 
Modules/posixmodule.o
"./Modules/posixmodule.c", line 5514.11: 1506-131 (W) Explicit dimension 
specification or initializer required for an auto or static array.
"./Modules/posixmodule.c", line 9328.64: 1506-280 (S) Function argument 
assignment between types "unsigned long" and "struct fsid_t" is not allowed.
Makefile:1765: recipe for target 'Modules/posixmodule.o' failed
make: *** [Modules/posixmodule.o] Error 1

Details (note rewrite from listing for line 5514)

 5514 | PyDoc_VAR(os_sched_param__doc__);
 5514 + static char os_sched_param__doc__[];
"./Modules/posixmodule.c", line 5514.11: 1506-131 (W) Explicit dimension 
specification or initializer required for an auto or static array.
 5515 |
 5516 | static PyStructSequence_Field sched_param_fields[] = {
 5517 | {"sched_priority", "the scheduling priority"},
 5518 | {0}
 5519 | };

--
components: Build
messages: 308775
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: AIX (xlc_r) compile error with Modules/posixmodule.c: Explicit dimension 
specification or initializer required
type: compile error
versions: Python 3.7

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

SVR4 - stands for AT System V Release 4 - the beginning (as I understand it) 
of shared libraries as (indivudual) .so files in UNIX. SVR3 (and earlier) used 
.a files (aka archives with members inside).

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue26439>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

x064 is AIX 5.3, x071 is AIX 6.1, x072 is AIX 7.1 - in the following output

On 11/20/2017 9:01 PM, Serhiy Storchaka wrote:
> Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment:
>
> What return commands `ifconfig`, `ifconfig -a`, `ifconfig -av`, `ip link 
> list`, `arp -an`, `lanscan -ai` (if not error)?
ifconfig:

ichael@x071:[/home/michael]dsh -n x064,x071,x072 ifconfig
x071: usage: ifconfig -a [ -d ] [ -u ] [ af ]
x071:    ifconfig -l [ -d ] [ -u ]
x071:    ifconfig interface
x071: [ af [ address [ dest_addr ] ] [ netmask mask ] [ 
broadcast addr ]
x071:  [ alias ] [ delete ] ]
x071: [ up ] [ down ] [ detach ]
x071: [ af first[alias] address [ ... ] ]
x071: [ site6 site_number ]
x071: [ metric n ]
x071: [ mtu n ]
x071: [ arp | -arp ]
x071: [ link0 | -link0 ] [ link1 | -link1 ] [ link2 | -link2 ]
x071: [ tcp_low_rto n | -tcp_low_rto ]
x071: [ inet6 scope n zone n ]
x071: [[ inet4 | inet6 ][address transfer newinterface]]
x071:    ifconfig tap_interface [ create | destroy ]
x064: usage: ifconfig -a [ -m ] [ -d ] [ -u ] [ af ]
x064:    ifconfig -l [ -d ] [ -u ]
x064:    ifconfig [ -m ] interface
x064: [ af [ address [ dest_addr ] ] [ netmask mask ] [ 
broadcast addr ]
x064:  [ alias ] [ delete ] ]
x064: [ up ] [ down ] [ detach ]
x064: [ af first[alias] address [ ... ] ]
x064: [ site6 site_number ]
x064: [ metric n ]
x064: [ mtu n ]
x064: [ arp | -arp ]
x064: [ link0 | -link0 ] [ link1 | -link1 ] [ link2 | -link2 ]
x064: [ tcp_low_rto n | -tcp_low_rto ]
x072: usage: ifconfig -a [ -d ] [ -u ] [ af ]
x072:    ifconfig -l [ -d ] [ -u ]
x072:    ifconfig interface
x072: [ af [ address [ dest_addr ] ] [ netmask mask ] [ 
broadcast addr ]
x072:  [ alias ] [ delete ] ]
x072: [ up ] [ down ] [ detach ]
x072: [ af first[alias] address [ ... ] ]
x072: [ site6 site_number ]
x072: [ metric n ]
x072: [ mtu n ]
x072: [ arp | -arp ]
x072: [ link0 | -link0 ] [ link1 | -link1 ] [ link2 | -link2 ]
x072: [ tcp_low_rto n | -tcp_low_rto ]
x072: [ inet6 scope n zone n ]
x072:    ifconfig tap_interface [ create | destroy ]

ifconfig -a:

michael@x071:[/home/michael]dsh -n x064,x071,x072 "ifconfig -a"
x071: en0: 
flags=1e084863,14c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
x071:   inet 192.168.129.71 netmask 0xff00 broadcast 192.168.129.255
x071:   inet 192.168.90.71 netmask 0xff00 broadcast 192.168.90.255
x071:   inet6 fe80::f8d1:8cff:fef7:6204%2/64
x071:    tcp_sendspace 262144 tcp_recvspace 262144 tcp_nodelay 1 rfc1323 1
x071: en1: 
flags=1e084863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
x071:   inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255
x071:    tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
x071: lo0: 
flags=e08084b,c0<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,LARGESEND,CHAIN>
x071:   inet 127.0.0.1 netmask 0xff00 broadcast 127.255.255.255
x071:   inet6 ::1%1/128
x071:    tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1
x064: en0: 
flags=1e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
x064:   inet 192.168.129.64 netmask 0xff00 broadcast 192.168.129.255
x064:    tcp_sendspace 131072 tcp_recvspace 65536
x064: lo0: 
flags=e08084b<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT>
x064:   inet 127.0.0.1 netmask 0xff00 broadcast 127.255.255.255
x064:   inet6 ::1/0
x064:    tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1
x072: en0: 
flags=1e084863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
x072:   inet 192.168.129.72 netmask 0xff00 broadcast 192.168.129.255
x072:    tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
x072: lo0: 
flags=e08084b,c0<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,LARGESEND,CHAIN>
x072:   inet 127.0.0.1 netmask 0xff00 broadcast 127.255.255.255
x072:   inet6 ::1%1/64
x072:    tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1

ifconfig -av:

michael@x071:[/home/michael]dsh -n x064,x071,x072 "ifconfig -av"
x071: ifconfig: illegal option -- v
x071: usage: ifconfig -a [ -d ] [ -u ] [ af ]
x071:    ifconfig -l [ -d ] [ -u ]
x071:    ifconfig interface
x071: [ af [ address [ dest_addr ] ] [ netmask mask ] [ 
broadcast addr ]
x071:  [ alias ] [ delete ] ]
x071: [ up ] [ down ] [ detach ]
x071: [ af first[alias] address [ ... ] ]
x071: [ site6 site_

[issue32095] AIX: ModuleNotFoundError: No module named '_ctypes' - make install fails

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

If I removed you from nosy - purely accidental - probably because you answered 
and I still had a dialog open with you not in it.

My apologies in any case. I'll be more careful should something like that 
happen again.

I am aware of the other dependencies - the only one I really care about for 
"master" is _ssl. Surprised that it would be missing. Will need some research 
on my side.

One of my "packaging" goals for python is to have it install by itself.
So I'll look at linking libffi statically so another fileset is not needed. 
(And remember to check for new libffi code when a new python version is 
released).

And - sorry for the duplicate!

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32095>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32095] AIX: ModuleNotFoundError: No module named '_ctypes' - make install fails

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

no. I'll install what I have atm.

Too bad - as now it will have an install dependency.

re: https://bugs.python.org/issue27976#msg274628 -- seems a warning that libffi 
is not available might be useful after all.

Question: is ffi still bundled for Darwin - even in 3.7? If yes, maybe it 
should also be bundled for AIX.

In any case, just installing a libffi.a library fixed the install (i.e., make; 
make install)

--
nosy:  -zach.ware
versions: +Python 3.8

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32095>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32095] AIX: ModuleNotFoundError: No module named '_ctypes' - make install fails

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

FYI: version 3.6.3 compiles and builds without this issue.

+ make install DESTDIR=/var/aixtools/python/Python/3.6.3.0 > 
.buildaix/install.out
+ mkinstallp.ksh /var/aixtools/python/Python/3.6.3.0 > .buildaix/mkinstallp.out

--
versions: +Python 3.7

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32095>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32095] AIX: ModuleNotFoundError: No module named '_ctypes' - make install fails

[Michael Felt]

New submission from Michael Felt <mich...@felt.demon.nl>:

after git clone from master:
make install fails to complete with:

Important - python is not installed already.
FYI: also note - build completes successfully with 2.7.14 (will download and 
check other python3 versions)

if test "xupgrade" != "xno"  ; then  case upgrade in  upgrade) 
ensurepip="--upgrade" ;;  install|*) ensurepip="" ;;  esac;   ./python -E -m 
ensurepip  $ensurepip --root=/ ;  fi
Traceback (most recent call last):
  File "/data/prj/python/git/src/python3-3.7.0.1/Lib/runpy.py", line 193, in 
_run_module_as_main
"__main__", mod_spec)
  File "/data/prj/python/git/src/python3-3.7.0.1/Lib/runpy.py", line 85, in 
_run_code
exec(code, run_globals)
  File "/data/prj/python/git/src/python3-3.7.0.1/Lib/ensurepip/__main__.py", 
line 5, in 
sys.exit(ensurepip._main())
  File "/data/prj/python/git/src/python3-3.7.0.1/Lib/ensurepip/__init__.py", 
line 204, in _main
default_pip=args.default_pip,
  File "/data/prj/python/git/src/python3-3.7.0.1/Lib/ensurepip/__init__.py", 
line 117, in _bootstrap
return _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "/data/prj/python/git/src/python3-3.7.0.1/Lib/ensurepip/__init__.py", 
line 27, in _run_pip
import pip
  File "/tmp/tmpg0jc_9p6/pip-9.0.1-py2.py3-none-any.whl/pip/__init__.py", line 
28, in 
  File "/tmp/tmpg0jc_9p6/pip-9.0.1-py2.py3-none-any.whl/pip/vcs/mercurial.py", 
line 9, in 
  File "/tmp/tmpg0jc_9p6/pip-9.0.1-py2.py3-none-any.whl/pip/download.py", line 
36, in 
  File "/tmp/tmpg0jc_9p6/pip-9.0.1-py2.py3-none-any.whl/pip/utils/glibc.py", 
line 4, in 
  File "/data/prj/python/git/src/python3-3.7.0.1/Lib/ctypes/__init__.py", line 
7, in 
from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'
make: 1254-004 The error code from the last command is 1.

--
components: Build
messages: 306581
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: AIX: ModuleNotFoundError: No module named '_ctypes' - make install fails
versions: Python 3.8

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32095>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt <mich...@felt.demon.nl> added the comment:

On 11/20/2017 5:22 PM, Serhiy Storchaka wrote:
> Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment:
>
> _unixdll_getnode, _ifconfig_getnode, and _arp_getnode were changed recently. 
> Are they still not working on AIX?
After a clone of master:
a) _unixdll_getnode is renamed to _unix_getnode
since the function _load_system_functions() still depends on 
find_library() - that always returns None, still not working.
Note also - find_library('uuid') will not work on a standard AIX - as 
the library libuuid.a does not exist, neither have I ever seen a shared 
library with the name libuuid.so.
FYI: Finally, "nm -Ae /usr/lib/libc.a | grep uuid" returns

root@x071:[/root]nm -Ae /usr/lib/libc.a | grep uuid
/usr/lib/libc.a[shr.o]: ._gen_localhost_uuid t 3248320
/usr/lib/libc.a[shr.o]: ._gen_localhost_uuid@AF22_8 t 3256928
/usr/lib/libc.a[shr.o]: .uuid__get_os_time   T 3234208
/usr/lib/libc.a[shr.o]: .uuid__uemul T 3236064
/usr/lib/libc.a[shr.o]: .uuid_compare    T 3237088
/usr/lib/libc.a[shr.o]: .uuid_copy   T 3236224
/usr/lib/libc.a[shr.o]: .uuid_create T 3240480
/usr/lib/libc.a[shr.o]: .uuid_create_nil T 3240160
/usr/lib/libc.a[shr.o]: .uuid_create_os  T 3256608
/usr/lib/libc.a[shr.o]: .uuid_disk   T 3252448
/usr/lib/libc.a[shr.o]: .uuid_equal  T 3238336
/usr/lib/libc.a[shr.o]: .uuid_equal_nc   T 3248384
/usr/lib/libc.a[shr.o]: .uuid_for_key    T 3249504
/usr/lib/libc.a[shr.o]: .uuid_from_string    T 3238944
/usr/lib/libc.a[shr.o]: .uuid_from_string_nc T 3248960
/usr/lib/libc.a[shr.o]: .uuid_get_address    t 3234720
/usr/lib/libc.a[shr.o]: .uuid_hash   T 3236384
/usr/lib/libc.a[shr.o]: .uuid_is_nil T 3237984
/usr/lib/libc.a[shr.o]: .uuid_is_nil_nc  T 3249408
/usr/lib/libc.a[shr.o]: .uuid_is_valid_string_nc T 3248512
/usr/lib/libc.a[shr.o]: .uuid_is_valid_string_nc@AF23_10 t 3257184
/usr/lib/libc.a[shr.o]: .uuid_localhost  T 3254208
/usr/lib/libc.a[shr.o]: .uuid_os_md5 t 3245248
/usr/lib/libc.a[shr.o]: .uuid_os_sha1    t 3245376
/usr/lib/libc.a[shr.o]: .uuid_to_string  T 3239648
/usr/lib/libc.a[shr.o]: .uuid_to_string_nc   T 3248608
/usr/lib/libc.a[shr.o]: _uuid_rmutex B  548664 12
/usr/lib/libc.a[shr.o]: _uuid_rmutex d  512480 4
/usr/lib/libc.a[shr.o]: getosuuid    U   -
/usr/lib/libc.a[shr.o]: setosuuid    U   -
/usr/lib/libc.a[shr.o]: uuid_c_version   D  503544 4
/usr/lib/libc.a[shr.o]: uuid_compare D  498436 12
/usr/lib/libc.a[shr.o]: uuid_copy    D  498412 12
/usr/lib/libc.a[shr.o]: uuid_create  D  498508 12
/usr/lib/libc.a[shr.o]: uuid_create_nil  D  498496 12
/usr/lib/libc.a[shr.o]: uuid_create_os   D  498616 12
/usr/lib/libc.a[shr.o]: uuid_disk    D  498592 12
/usr/lib/libc.a[shr.o]: uuid_equal   D  498460 12
/usr/lib/libc.a[shr.o]: uuid_equal_nc    D  498520 12
/usr/lib/libc.a[shr.o]: uuid_for_key D  498580 12
/usr/lib/libc.a[shr.o]: uuid_from_string D  498472 12
/usr/lib/libc.a[shr.o]: uuid_from_string_nc  D  498556 12
/usr/lib/libc.a[shr.o]: uuid_g_nil_uuid  D  432472 16
/usr/lib/libc.a[shr.o]: uuid_g_nil_uuid  d  512476 4
/usr/lib/libc.a[shr.o]: uuid_hash    D  498424 12
/usr/lib/libc.a[shr.o]: uuid_is_nil  D  498448 12
/usr/lib/libc.a[shr.o]: uuid_is_nil_nc   D  498568 12
/usr/lib/libc.a[shr.o]: uuid_is_valid_string_nc D 498532  12
/usr/lib/libc.a[shr.o]: uuid_localhost   D  498604 12
/usr/lib/libc.a[shr.o]: uuid_to_string   D  498484 12
/usr/lib/libc.a[shr.o]: uuid_to_string_nc    D  498544 12

i.e., there is nothing with uuid_generate in it.

_arp_getnode()
AIX does not return any value for itself.
Neither does Centos, (so I expect RHEL will also not), and my old 
debians do not either.

So, after summary - these three functions still do nothing/do not work 
on AIX 6.1 or AIX 7.1 (cannot test AIX 7.2).

And - as before, netstat -ia - when looking at ':', still returns

01:00:5e:00:00:01

for every interface.

>
> --
> nosy: +serhiy.storchaka
> versions: +Python 3.7 -Python 3.3, Python 3.4, Python 3.5
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue28009>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28009>
___
___
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)

 

[issue29545] Python behavioral difference between Linux and AIX

[Michael Felt]

Michael Felt added the comment:

Curious.

First pass: using python2.7.12 also hanged as program, on the close()

second pass: interactive - do the read first, then the close - seems to work:

root@x064:[/data/prj/python/issues/29545]cat hello.py
#!/usr/bin/env python
import errno
import os
import pty
from subprocess import Popen, STDOUT

master_fd, slave_fd = pty.openpty()
proc = Popen(['./hello'],stdout=slave_fd, close_fds=True)
os.close(slave_fd)
data = os.read(master_fd, 512)
print('got ' + repr(data))
root@x064:[/data/prj/python/issues/29545]python
Python 2.7.12 (default, Sep 29 2016, 12:02:17) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import errno
import os
import pty
from subprocess import Popen, STDOUT
>>> >>> >>> >>>
>>> master_fd, slave_fd = pty.openpty()
>>> master_fd
3
>>> slave_fd
4
>>> proc = Popen(['./hello'],stdout=slave_fd, close_fds=True)
>>> data = os.read(master_fd, 512)
>>> datat
'hello world\r\n'
>>> os.close(slave_fd)
>>> print (got '
  File "", line 1
print (got '
   ^
SyntaxError: EOL while scanning string literal
>>> print('got ' + repr(data))
got 'hello world\r\n'
>>> quit()

pass 3:
swap the close() and the read() and the program works fine.

"hello.py" 11 lines, 265 characters

root@x064:[/data/prj/python/issues/29545]cat hello.py
#!/usr/bin/env python
import errno
import os
import pty
from subprocess import Popen, STDOUT

master_fd, slave_fd = pty.openpty()
proc = Popen(['./hello'],stdout=slave_fd, close_fds=True)
data = os.read(master_fd, 512)
os.close(slave_fd)
print('got ' + repr(data))

root@x064:[/data/prj/python/issues/29545]./hello.py
got 'hello world\r\n'
root@x064:[/data/prj/python/issues/29545]

--
nosy: +aixto...@gmail.com

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29545>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: When will os.remove fail?

[Michael Felt]

On 13/03/2017 02:51, Steve D'Aprano wrote:

On Mon, 13 Mar 2017 05:45 am, Alain Ketterlin wrote:


Steve D'Aprano  writes:

[...]

It seems that os.remove on Linux will force the delete even if the file
is read-only or unreadable, provided you own the file.

Your permissions on the file do not really matters. It's all about your
permissions on the parent directory (removing a file is really modifying
the parent dir). Actually, it is even slightly more complicated. Here is
an excerpt of the unlink(2) call (which does the job) listing common
error cases:
Granted, I am a bit behind in the discussion - and I know nothing about 
how Windows manages this since DOS 3.3 - there it also called unlink().


rm is the command we run. The system call it uses to remove a file is 
unlink(). unlink() removes the "link" of the name in the directory to 
the inode and lowers the count of the number of links to the file (a 
hard link is an additional directory link to the inode). To modify the 
inode (link counter) you need to own the file or have (super user) 
elevated privelidges. To remove the directory link you need to have 
write privilidge on the (special file type) directory.


On UNIX/Linux when the link count is zero the inode and the filesystem 
blocks it provides access to are cleared if no process is holding the 
file open. This means it is easy to unlink() (not remove!) an open file. 
The inode is active and can be used "normally". FYI, the classic 
mktemp() library routine on UNIX would create a file, open (better 
create) the file, unlink the file, and then return file descriptor. 
Regardless of how the program ended (crash or normal) the temp file 
would be cleaned up on exit.


I would be guessing - but FAT and/or NTFS may not be written to clean up 
on a file with no "links" - and this is why Windows behavior seems to be 
more restrictive than POSIX/LINUX.



Thanks for the detailed explanation, and to everyone else who corrected my
misunderstanding.





--
https://mail.python.org/mailman/listinfo/python-list

Re: best way to ensure './' is at beginning of sys.path?

[Michael Felt]

On 04-Feb-17 02:07, Cameron Simpson wrote:

On 03Feb2017 17:21, Wildman  wrote:

On Sat, 04 Feb 2017 09:25:42 +1100, Cameron Simpson wrote:
Also, what you describe with rc.local wouldn't work anyway, even if 
it had ben

what was asked.


Of course, you are correct.  I don't know where my head
was.  I think my tongue got in front of my eye teeth and
I could not see what I was saying.  :-)

If anyone is interested the correct way is to add this to
/etc/profile (at the bottom):

PATH=$PATH:./
export PATH


Indeed. But this should usually be accompanied by the advice that this 
isn't a good idea. Having one's commands at the mercy of whatever 
directory one is standing in is a recipe for being subverted. While 
the risk is lessened by having "." at the end of the search path, that 
just means the attacker (== other user of this system) has to name 
their trojan horse commands after typing errors, such as the ever 
popular "gerp" search programme.


Even with Python I'd feel it is better to not have "." in the 
sys.path; I'd be happier with a full path to a preferred source of 
modules. (Yes, I know Python likes to search the current directory for 
modules, notmy favourite feature.)


This sound like something that could be hidden, read moved, if not 
removed - to a feature only available if built with something resembling 
a --dev-build flag (Python3.7 of course, as there may be earlier 
projects that depend on it - certainly officially deprecate in all other 
Python3 releases - there never being a Python2.8 a deprecate in 
Python2.7 is pointless).

Cheers,
Cameron Simpson 


--
https://mail.python.org/mailman/listinfo/python-list

[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 &q

[issue18235] _sysconfigdata.py wrong on AIX installations

[Michael Felt]

Michael Felt added the comment:

OK - so details on the failing tests - for the record only.

However, I would appreciate some 'expert' feedback on what is expected to be 
happening in this test:

==
FAIL: test_sysconfig_compiler_vars 
(distutils.tests.test_sysconfig.SysconfigTestCase)
--
Traceback (most recent call last):
  File "/data/prj/python/Python-2.7.13/Lib/distutils/tests/test_sysconfig.py", 
line 102, in test_sysconfig_compiler_vars
self.assertEqual(global_sysconfig.get_config_var('LDSHARED'), 
sysconfig.get_config_var('LDSHARED'))
AssertionError: 'Modules/ld_so_aix xlc_r -bI:Modules/python.exp' != 
'/opt/lib/python2.7/config/ld_so_aix xlc_r 
-bI:/opt/lib/python2.7/config/python.exp'

--

BULK details...

==
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
--
Traceback (most recent call last):
  File "/data/prj/python/Python-2.7.13/Lib/distutils/tests/test_install.py", 
line 216, in test_record_extensions
cmd.run()
  File "/data/prj/python/Python-2.7.13/Lib/distutils/command/install.py", line 
563, in run
self.run_command('build')
  File "/data/prj/python/Python-2.7.13/Lib/distutils/cmd.py", line 326, in 
run_command
self.distribution.run_command(command)
  File "/data/prj/python/Python-2.7.13/Lib/distutils/dist.py", line 972, in 
run_command
cmd_obj.run()
  File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build.py", line 
127, in run
self.run_command(cmd_name)
  File "/data/prj/python/Python-2.7.13/Lib/distutils/cmd.py", line 326, in 
run_command
self.distribution.run_command(command)
  File "/data/prj/python/Python-2.7.13/Lib/distutils/dist.py", line 972, in 
run_command
cmd_obj.run()
  File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", 
line 340, in run
self.build_extensions()
  File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", 
line 449, in build_extensions
self.build_extension(ext)
  File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", 
line 531, in build_extension
target_lang=language)
  File "/data/prj/python/Python-2.7.13/Lib/distutils/ccompiler.py", line 691, 
in link_shared_object
extra_preargs, extra_postargs, build_temp, target_lang)
  File "/data/prj/python/Python-2.7.13/Lib/distutils/unixccompiler.py", line 
202, in link
raise LinkError, msg
LinkError: command '/opt/lib/python2.7/config/ld_so_aix' failed with exit 
status 1

==
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
--
Traceback (most recent call last):
  File "/data/prj/python/Python-2.7.13/Lib/distutils/tests/test_config_cmd.py", 
line 46, in test_search_cpp
match = cmd.search_cpp(pattern='xxx', body='/* xxx */')
  File "/data/prj/python/Python-2.7.13/Lib/distutils/command/config.py", line 
206, in search_cpp
src, out = self._preprocess(body, headers, include_dirs, lang)
  File "/data/prj/python/Python-2.7.13/Lib/distutils/command/config.py", line 
129, in _preprocess
self.compiler.preprocess(src, out, include_dirs=include_dirs)
  File "/data/prj/python/Python-2.7.13/Lib/distutils/unixccompiler.py", line 
113, in preprocess
raise CompileError, msg
CompileError: command 'xlc_r' failed with exit status 40

==
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
--
Traceback (most recent call last):
  File "/data/prj/python/Python-2.7.13/Lib/distutils/tests/test_build_ext.py", 
line 63, in test_build_ext
cmd.run()
  File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", 
line 340, in run
self.build_extensions()
  File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", 
line 449, in build_extensions
self.build_extension(ext)
  File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", 
line 531, in build_extension
target_lang=language)
  File "/data/prj/python/Python-2.7.13/Lib/distutils/ccompiler.py", line 691, 
in link_shared_object
extra_preargs, extra_postargs, build_temp, target_lang)
  File "/data/prj/python/Python-2.7.13/Lib/distutils/unixccompiler.py", line 
202, in link
raise LinkError, ms

[issue18235] _sysconfigdata.py wrong on AIX installations

[Michael Felt]

Michael Felt added the comment:

I am back at this: (note: short answer to msg277745 - No. does not work for me)

As ... expressed before, this needs to work in three contexts:

2) In-tree testing of build module feature (test_distutils).

Below are results of 'in tree' and 'out of tree' testing. in/out seems to have 
no (more) impact.

msg219888 also has a patch - that moves the code back to where it originally 
was: _init_posix

But - same issue - ld_so_aix is not found. (notice the "src" in string of 
'threading.py')
[112/401/2] test_distutils
xlc_r: 1501-218 (S) file _configtest.i contains an incorrect file suffix
unable to execute '/opt/lib/python2.7/config/ld_so_aix': No such file or 
directory
Warning -- os.environ was modified by test_distutils
test test_distutils failed -- multiple errors occurred; run in verbose mode for 
details
[113/401/3] test_dl
test_dl skipped -- No module named dl
[114/401/3] test_docxmlrpc
/data/prj/python/src/Python-2.7.13/Lib/threading.py:846: DeprecationWarning: 
sys.exc_clear() not supported in 3.x; use except clauses
  self.__exc_clear()
[115/401/3] test_dumbdbm
root@x064:[/data/prj/python/Python-2.7.13]


Now, back to 'in tree' with patch from msg219888 (no "src" in path)

root@x064:[/data/prj/python/Python-2.7.13]find . -name _sysconfigdata\*.py -ls 
-exec grep LDSHARED {} \;
48056876   16 -rw-r-  1 root  100015362 Jan 24 15:07 
./build/lib.aix-5.3-2.7/_sysconfigdata.py
 'BLDSHARED': 'Modules/ld_so_aix xlc_r -bI:Modules/python.exp',
 'LDSHARED': '/opt/lib/python2.7/config/ld_so_aix xlc_r 
-bI:/opt/lib/python2.7/config/python.exp',
[112/401/2] test_distutils
xlc_r: 1501-218 (S) file _configtest.i contains an incorrect file suffix
unable to execute '/opt/lib/python2.7/config/ld_so_aix': No such file or 
directory
Warning -- os.environ was modified by test_distutils
test test_distutils failed -- multiple errors occurred; run in verbose mode for 
details
[113/401/3] test_dl
test_dl skipped -- No module named dl
[114/401/3] test_docxmlrpc
/data/prj/python/Python-2.7.13/Lib/threading.py:846: DeprecationWarning: 
sys.exc_clear() not supported in 3.x; use except clauses
  self.__exc_clear()

Conclusion:
** As the code is - that is removed means the environment variable in 
sysconfigdata.py is correct,
   I would suggest the patch is to remove the 6 lines there.
   Further, the addition of the code below (per msg219888) has no effect, 
including it is not needed.

The .dist file is from the source tarball from last december for 2.7.13

michael@x071:[/data/prj/python/src]diff -u  Python-2.7.13/Lib/sysconfig.py.dist>
--- Python-2.7.13/Lib/sysconfig.py.dist 2016-12-17 20:05:06 +
+++ Python-2.7.13/Lib/sysconfig.py  2017-01-24 14:56:20 +
@@ -307,12 +307,6 @@
 msg = msg + " (%s)" % e.strerror
 raise IOError(msg)

-# On AIX, there are wrong paths to the linker scripts in the Makefile
-# -- these paths are relative to the Python source, but when installed
-# the scripts are in another directory.
-if _PYTHON_BUILD:
-vars['LDSHARED'] = vars['BLDSHARED']
-
 # There's a chicken-and-egg situation on OS X with regards to the
 # _sysconfigdata module after the changes introduced by #15298:
 # get_config_vars() is called by get_platform() as part of the
@@ -355,6 +349,11 @@
 # _sysconfigdata is generated at build time, see _generate_posix_vars()
 from _sysconfigdata import build_time_vars
 vars.update(build_time_vars)
+# On AIX, there are wrong paths to the linker scripts in the Makefile
+# -- these paths are relative to the Python source, but when installed
+# the scripts are in another directory.
+if _PYTHON_BUILD:
+vars['LDSHARED'] = vars['BLDSHARED']

 def _init_non_posix(vars):
 """Initialize the module as appropriate for NT"""

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18235>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18235] _sysconfigdata.py wrong on AIX installations

[Michael Felt]

Michael Felt added the comment:

As far as issue10656 and this issue are concerned:

Python-3.4 is out of context (but 3.4.6 was just released) - and does not work 
with 'out of tree' builds. 

The other versions: 2.7.13, 3.5.3 and 3.6.0 do build out-of-tree.
Note 3.5.3 and 3.6.0 use a different name for sysconfigdata.py

Notes:

FYI: regarding build and src in different directories

Not working...

unable to execute '../src/Python-3.4.6/Modules/ld_so_aix': No such file or 
directory
unable to execute '../src/Python-3.4.6/Modules/ld_so_aix': No such file or 
directory
 many many times

Concludes with:
ImportError: No module named 'time'
make: 1254-004 The error code from the last command is 1.
make: 1254-005 Ignored error code 1 from last command.
../src/Python-3.4.6/install-sh: ../src/Python-3.4.6/Modules/ld_so_aix does not 
exist
make: 1254-004 The error code from the last command is 1.

root@x064:[/data/prj/python/Python-3.4.6]find . -name _sysconfigdata.py -ls 
-exec grep LDSHARED {} \;
48049316   19 -rw-r-  1 root  felt 19209 Jan 24 13:55 
./build/lib.aix-5.3-3.4/_sysconfigdata.py
 'BLDSHARED': '/opt/lib/python3.4/config/ld_so_aix xlc_r '
 'LDSHARED': '/opt/lib/python3.4/config/ld_so_aix xlc_r '

+++ Working 

Working: 2.7.13 -- Note: the 'lines' in sysconfig.py are removed:
root@x064:[/data/prj/python/Python-2.7.13.0]find . -name _sysconfigdata\*.py 
-ls -exec grep LDSHARED {} \;
48038426   16 -rw-r-  1 root  felt 15807 Jan 24 13:36 
./build/lib.aix-5.3-2.7/_sysconfigdata.py
 'BLDSHARED': 'Modules/ld_so_aix xlc_r -bI:Modules/python.exp',
 'LDSHARED': '/opt/lib/python2.7/config/ld_so_aix xlc_r 
-bI:/opt/lib/python2.7/config/python.exp',

Working: 3.5.3
48049196   21 -rw-r-  1 root  felt 20640 Jan 24 13:55 
./build/lib.aix-5.3-3.5/_sysconfigdata.py
 'BLDSHARED': '/opt/lib/python3.5/config-3.5m/ld_so_aix xlc_r '
 'LDSHARED': '/opt/lib/python3.5/config-3.5m/ld_so_aix xlc_r '

Working: 3.6.0 -- Note new file name!!
root@x064:[/data/prj/python/Python-3.6.0]find . -name _sysconfigdata\*.py -ls 
-exec grep LDSHARED {} \;
47794146   20 -rw-r-  1 root  felt 20394 Jan 24 13:49 
./build/lib.aix-5.3-3.6/_sysconfigdata_m_aix5_.py
 'BLDSHARED': 'Modules/ld_so_aix xlc_r -bI:Modules/python.exp',
 'LDSHARED': '/opt/lib/python3.6/config-3.6m/ld_so_aix xlc_r '

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18235>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18235] _sysconfigdata.py wrong on AIX installations

[Michael Felt]

Michael Felt added the comment:

re: msg286115, 

1) Building modules in the tree during the build process.
** if "in the tree" means building outside of source - such as:
../src/python-X.Y.Z/configure ...
make

** the tarball for Python-2.7.13 is building from 
../src/Python-2.7.13/configure where as ../src/Python-2.7.12/configure and the 
earlier (ones I tried) were not.

** However, 'make distclean' is not working. 
   Further details in a later issue - this bit about make distclean id merely 
FYI. 

2) In-tree testing of build module feature (test_distutils).

** Is this as simple as (from the 'build directory':
make test 

** shall check this later, make test in general seems to be working - is 
test_distutils a specific test you want verified?
3) Building and installing modules with an installed version of Python.
** FYI: this will work with the 5 lines deleted - as I mentioned above.
   This is how I manually patched _sysconfigdata.py in Python-2.7.12 when I ran 
into this.

Now reading the other comments from last night...

re: 286172 and 286173

Short response:
it looks as if patches elsewhere in the 'auto' config files has taken care of 
this issue - at least for Python-2.7

I shall download and check the latest Python-3.{4|5|6} and report back.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18235>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18235] _sysconfigdata.py wrong on AIX installations

[Michael Felt]

Michael Felt added the comment:

You guys are the experts. I can only comment on what I see. IMHO: the file 
_sysconfigdata.py is more accurate with nothing in it.

I am clearly confused by whatever process this is. If you believe it is more 
accurate to have the BLD variable 'inaccurate' in this file - and that we just 
need to "believe" that it has the correct value during the build (which, 
starting with version 2.7.13 seems to be the case, as I am able to build in a 
different directory - and could not do this with version 2.7.10 (first time I 
tried using separate directories).

In short, I have no expert opinion on this. My naive view is that both 
variables being accurate in the file is more accurate. In any case, the patch 
is needed for a working _sysconfigdata.py and integration with something such 
as "pip build ...". Only after I learned about 'pip' did I ever run into this, 
i.e., only people who are trying to install something extra have issues here. I 
have been 'patching' _sysconfigdata.py manually so that things work normally.

I hope my feedback helps you move forward on this.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18235>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18235] _sysconfigdata.py wrong on AIX installations

[Michael Felt]

Michael Felt added the comment:

This is "only" for Python-2.7 (for now). The others will be tested as I am able.

Working with the patch submitted 2013-10-19 (aka 
https://bugs.python.org/file32229/issue18235.patch)

A) Without/before the patch:

root@x064:[/data/prj/python/Python-2.7.13.0]grep LDSHARED 
./build/lib.aix-5.3-2.7/_sysconfigdata.py
 'BLDSHARED': 'Modules/ld_so_aix xlc_r -bI:Modules/python.exp',
 'LDSHARED': 'Modules/ld_so_aix xlc_r -bI:Modules/python.exp',

B) Apply the patch:
diff -r 0a26ef834a49 Lib/sysconfig.py
--- a/Lib/sysconfig.py  Sat Oct 19 14:24:44 2013 +0200
+++ b/Lib/sysconfig.py  Sat Oct 19 11:46:10 2013 -0700
@@ -368,7 +368,7 @@
 # -- these paths are relative to the Python source, but when installed
 # the scripts are in another directory.
 if _PYTHON_BUILD:
-vars['LDSHARED'] = vars['BLDSHARED']
+vars['BLDSHARED'] = vars['LDSHARED']

After the patch:

root@x064:[/data/prj/python/Python-2.7.13.0]grep LDSHARED 
./build/lib.aix-5.3-2.7/_sysconfigdata.py
 'BLDSHARED': '/opt/lib/python2.7/config/ld_so_aix xlc_r 
-bI:/opt/lib/python2.7/config/python.exp',
 'LDSHARED': '/opt/lib/python2.7/config/ld_so_aix xlc_r 
-bI:/opt/lib/python2.7/config/python.exp',

Which makes me think - maybe NOTHING is needed - as 'BLDSHARED' should be 
Modules/ld_so_aix,
while  'LDSHARED' should be '/opt/lib/python2.7/config/ld_so_aix

Rather than actual deletes: commented out to (after patch was applied)

C: if: statement and assignment - commented out
diff -ru Python-2.7.13/Lib/sysconfig.py Python-2.7.13.0/Lib/sysconfig.py
--- Python-2.7.13/Lib/sysconfig.py  2016-12-17 20:05:06 +
+++ Python-2.7.13.0/Lib/sysconfig.py2017-01-23 14:39:31 +
@@ -310,8 +310,8 @@
 # On AIX, there are wrong paths to the linker scripts in the Makefile
 # -- these paths are relative to the Python source, but when installed
 # the scripts are in another directory.
-if _PYTHON_BUILD:
-vars['LDSHARED'] = vars['BLDSHARED']
+#if _PYTHON_BUILD:
+#vars['BLDSHARED'] = vars['LDSHARED']

root@x064:[/data/prj/python/Python-2.7.13.0]grep LDSHARED 
./build/lib.aix-5.3-2.7/_sysconfigdata.py
 'BLDSHARED': 'Modules/ld_so_aix xlc_r -bI:Modules/python.exp',
 'LDSHARED': '/opt/lib/python2.7/config/ld_so_aix xlc_r 
-bI:/opt/lib/python2.7/config/python.exp',
root@x064:[/data/prj/python/Python-2.7.13.0]

So, perhaps the best patch 'today', versus what may have been best in 2013 - is 
to remove the 5 lines starting with # On AIX, ...

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18235>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18235] _sysconfigdata.py wrong on AIX installations

[Michael Felt]

Michael Felt added the comment:

Ok. I shall rebuild from scratch.

When I do, I start from a "clean" system - only the compiler and my mkinstallp 
helper script.

I am adding the latest zlib for what I would package but I shall forgoe that 
for this test.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18235>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18235] _sysconfigdata.py wrong on AIX installations

[Michael Felt]

Michael Felt added the comment:

I did not go through a whole build process.

Changing:


if _PYTHON_BUILD:
vars['BLDSHARED'] = vars['LDSHARED']
to

if _PYTHON_BUILD:
vars['LDSHARED'] = vars['BLDSHARED']

is not going to help if both variables are wrong in _sysconfigdata*.py

Also,

The patch is not applied in any version - yet the values in _sysconfigdata*.py 
are different, i.e., version dependent (without the patch).

If I errored in my assumption that the file being patched is reading 
_sysconfigdata*.py then I will need to patch and build from scratch to see the 
effect on _sysconfigdata.py

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18235>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

[Michael Felt]

Michael Felt added the comment:

OOPS: I have a ... above, meant to be a link to a message.

I also needed to 'patch' util.py - with 32-bit build with something like this:
--- src/python-2.7.13/Lib/ctypes/util.py2016-12-17 20:05:05 +
+++ python-2.7.13.0/Lib/ctypes/util.py  2017-01-13 13:29:12 +
@@ -299,6 +299,10 @@
 print cdll.LoadLibrary("libcrypto.dylib")
 print cdll.LoadLibrary("libSystem.dylib")
 print cdll.LoadLibrary("System.framework/System")
+elif sys.platform[:3] == "aix":
+from ctypes import CDLL
+RTLD_MEMBER =  0x0004
+print CDLL("libc.a(shr.o)", RTLD_MEMBER)
 else:
 print cdll.LoadLibrary("libm.so")
 print cdll.LoadLibrary("libcrypt.so")


And 64-bit with:

1: elif sys.platform[:3] == "aix":
1: from ctypes import CDLL
1: RTLD_MEMBER =  0x0004
1: print CDLL("libc_64.a(shr.o)", RTLD_MEMBER)

The respective output is:

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


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


--

___
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

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

[Michael Felt]

Michael Felt added the comment:

I would like to say:
a) I am happy this is being considered for Python3-3.7

b) I still believe it is a "bug" plain and simple - it (find_library()) cannot 
work in "normal" situations. Why "IBM" or others never addressed this is beyond 
me - but - imho - that is a poor argument for not fixing it.

FYI: As I have documented in ... this does not mean that ctypes.CDLL is 
incapable of loading a library. If you know the 'magic', aka what is not being 
provided by this "implementation dependent" module - it is possible to load 
either a .so file (actually a file by any name as long as it is a shared 
archive) - or an AIX-style .a archive with shared libraries stored internally 
as "archive members" - again, any member name is acceptable.

The bug: The "default code" behind an "else:" block depends on the presence of 
the program "/sbin/ldconfig" to create a list of shared libraries. Normally, 
this program is not installed on an AIX system (certainly not production - 
maybe a system with gcc environment and using the gcc ld rather than the AIX ld 
(the latter being normal).

Using python -m trace -C /tmp --count Lib/src/util.py The following (key) 
counts are reported.

This is all that is being called - so when /sbin/ldonfig is not installed 
(which is usual) - so this code can only return 'None'.

Environment: AIX 5.3, AIX 6.1, AIX 7.1 - all identical

root@x064:[/]ls -l /sbin/ld*
ls: 0653-341 The file /sbin/ld* does not exist.

michael@x071:[/home/michael]ls /sbin/ld*
ls: cannot access '/sbin/ld*': A file or directory in the path name does not 
exist.
(GNU coreutils ls here)

root@x062:[/]ls /sbin/ld*
ls: 0653-341 The file /sbin/ld* does not exist.

So, obviously the sys.popen() call below will always 'fail'.


The basic trace from util.py:
1: if os.name == "posix":
   # find and load_version
1: print find_library("m")
1: print find_library("c")
1: print find_library("bz2")


And how this is called:

   else:

1: def _findSoname_ldconfig(name):
3: import struct
3: if struct.calcsize('l') == 4:
   machine = os.uname()[4] + '-32'
   else:
3: machine = os.uname()[4] + '-64'
3: mach_map = {
3: 'x86_64-64': 'libc6,x86-64',
3: 'ppc64-64': 'libc6,64bit',
3: 'sparc64-64': 'libc6,64bit',
3: 's390x-64': 'libc6,64bit',
3: 'ia64-64': 'libc6,IA-64',
   }
3: abi_type = mach_map.get(machine, 'libc6')

   # XXX assuming GLIBC's ldconfig (with option -p)
3: expr = r'\s+(lib%s\.[^\s]+)\s+\(%s' % (re.escape(name), 
abi_type)
3: f = os.popen('LC_ALL=C LANG=C /sbin/ldconfig -p 2>/dev/null')
3: try:
3: data = f.read()
   finally:
3: f.close()
3: res = re.search(expr, data)
3: if not res:
3: return None
   return res.group(1)

1: def find_library(name):
3: return _findSoname_ldconfig(name) or 
_get_soname(_findLib_gcc(name))


And with python2-2.7.13 - the counts start the same - but the result is the 
same - by definition 'None' because subprocess.Popen() also
does not have any output to search...

1: if os.name == "posix":
   # find and load_version
1: print find_library("m")
1: print find_library("c")
1: print find_library("bz2")

   else:

1: def _findSoname_ldconfig(name):
3: import struct
3: if struct.calcsize('l') == 4:
3: machine = os.uname()[4] + '-32'
   else:
   machine = os.uname()[4] + '-64'
3: mach_map = {
3: 'x86_64-64': 'libc6,x86-64',
3: 'ppc64-64': 'libc6,64bit',
3: 'sparc64-64': 'libc6,64bit',
3: 's390x-64': 'libc6,64bit',
3: 'ia64-64': 'libc6,IA-64',
   }
3: abi_type = mach_map.get(machine, 'libc6')

   # XXX assuming GLIBC's ldconfig (with option -p)
3: expr = r'\s+(lib%s\.[^\s]+)\s+\(%s' % (re.escape(name), 
abi_type)

3: env = dict(os.environ)
3: env['LC_ALL'] = 'C'
3: env['LANG'] = 'C'
3: null = open(os.devnull, 'wb')
3: try:
3: with null:
3: p = subprocess.Popen(['/sbin/ldconfig', '-p'],
3: