Michael Felt added the comment:
aixutil.py renamed as _aixutil.py and other changes in response to Martin's
comments of 4 June
--
Added file: http://bugs.python.org/file43311/_aixutil.py
___
Python tracker <rep...@bugs.python.org>
Michael Felt added the comment:
aixutil.py renamed as _aixutil.py and other changes in response to Martin's
comments of 4 June
delta of changes to __init__.py, util.py, and test/test_loading.py
--
Added file: http://bugs.python.org/file43312/python.Lib.ctypes.160608.patch
Michael Felt added the comment:
* You may also just modify my "attempt" in _aixutil.py
I recall you said something about the p.wait() being a potential to hang, but I
also want to be sure the subprocess has exited properly - as it is not
something to be running in parallel - a
Michael Felt added the comment:
As a separate file in the hope it re-fits into Mercurial better
--
Added file: http://bugs.python.org/file43073/aixutil.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Michael Felt added the comment:
without aixutil.py - hopefully better for Mercurial import
--
Added file: http://bugs.python.org/file43074/Python2.Lib.ctypes.160531.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Michael Felt added the comment:
_aixutil.py to be paired with Python2.Lib.ctypes.16.06.11.patch
--
Added file: http://bugs.python.org/file43425/_aixutil.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Michael Felt added the comment:
The patch for Python2 - however, only now see the change in selections for
version. Will need to redo/test Lib/ctypes/*.py in newer version.
Note also, the additional tests in util.py are for my testing - I do not expect
them to stay, but I do want you aware
Michael Felt added the comment:
updated patch for Python 2.7 (shall adopt and submit new patch for Python3
based on this - next week)
used gnu diff to generate diff output.
Additional tests in util.py are for demo only, would expect them to be removed,
however, the additional test in test
Michael Felt added the comment:
The _dlopen call in __init__.py I have been able to fix (hack) with the
following:
root@x064:[/data/prj/aixtools/python/python-2.7.10/Lib/ctypes]diff -u
__init__.py /opt/lib/python2.7/ctypes/__init__.py
--- __init__.py 2015-05-23 16:09:01 +
+++ /opt/lib
Changes by Michael Felt <aixto...@gmail.com>:
--
title: ctypes.util.find_library fails ALWAYS when gcc is not used ->
ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)
___
Python tracker <rep...@bugs.pytho
New submission from Michael Felt:
I have successful enough with python 2.7.10 (for building cloud-init),
including it finding openssl libraries during the installation od setuptools
(before installing pip).
I have also been able to assemble saltstack - BUT - salt-master and salt-minion
fail
Michael Felt added the comment:
Oops: forgot the example output:
root@x064:[/data/prj/aixtools/src]python -m ctypes.util
libm.a(libm.so)
libc.a(libc.so)
libbz2.a(libbz2.so)
libcrypto.a(libcrypto.so)
libcrypt.a(libcrypt.so)
--
___
Python tracker
Michael Felt added the comment:
The following demonstrates the basics.
cdll.LoadLibrary will load a .so file if it can be located (you will have to
believe me as I forgot to include the test in this last batch)
Further, when given the AIX format for loading a member of an archive
(e.g
Michael Felt added the comment:
it was, partly, about the technical details - but I feel I have found the key
bits - /full/path/libNAME.a(libNAME.so) + dlflags RTLD_NOW + RTLD_MEMBER for
"native" AIX support.
Additionally, a patch should not break what might be working for some (via
Michael Felt added the comment:
FYI: getting objdump is not too hard...
root@x064:[/data/prj/gnu/binutils-2.25.1]v/null /usr/lib/libcrypto.a <
In archive /usr/lib/libcrypto.a:
libcrypto.so: file format aixcoff-rs6000
libcrypto.so.0.9.8: file format aixcoff-rs6
Michael Felt added the comment:
p.s. On a debian (on POWER) system, the function is working, but the test seems
a bit broken as well, i.e., cdll.LoadLibrary("libm.so") is not working even
though
if os.name == "posix":
# find and load_version
p
Michael Felt added the comment:
Further testing...
I added an extremely simple hack in util.py so that a archive (AIX library)
name got returned.
Also in this case - the print cdll.LoadLibrary("libc.a") fails.
+74 if os.name == "posix" and sys.platform == "
Michael Felt added the comment:
Last message (back to debian, and minor changes to learn expected behavior)
if sys.platform == "darwin":
print cdll.LoadLibrary("libm.dylib")
print cdll.LoadLibrary("libcrypto.dylib")
Michael Felt added the comment:
the basic process I have used repeatedly (for calling ./configure) to package
python, and many other things has not changed.
Today, I repackaged version 2.7.10 (the file listed in 2.7.10.0) just to test
the process I was using with 2.7.11
I learned that 2.7.10
Michael Felt added the comment:
fyi: just completed a test both as 32 and 64 bit build.
However, openssl-1.0.1.514 does not work in 64-bit mode (packaging error).
Fortunately, openssl-1.0.1.515 (released 02-March-2016) fixes that.
In short, 64-bit build is dependent on openssl-1.0.1.515
Here
Michael Felt added the comment:
Ah, good news - the build is successful ONCE I open the file
./Lib/ctypes/util.py and find the (hiding) tab characters and replace them with
8 space characters. (And I had tried so hard to check for that in advance).
So, if you apply the patch - it may need
Michael Felt added the comment:
Hope it is okay for me to close this. As it is working with the additional flag
to configure.
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Michael Felt added the comment:
The patch works when installed on top of pre-compiled version (e.g., copy the
two files to /opt/lib/python2.7/ctypes/
but there seems to be a nasty side-effect when trying to build.
make completes, but make install fails during a compile step.
Please assist
Michael Felt added the comment:
FYI: build as 64-bit (and shall only build as 64-bit from now I expect)
and the output works as:
==
aixtools.python:aixtools.python.man.en_US:2.7.11.0::I:C:N:man pages0::
aixtools.python:aixtools.python.rte:2.7.11.0::I:C
Michael Felt added the comment:
FYI: when build and src are the same directory, there is no error message.
However, when src and build are in seperate directories (e.g.,
build = '.',
src = '../src/python-2.7.11'
the following message occurs MANY times:
unable to execute '../src/python-2.7.11
Michael Felt added the comment:
wonderful suggestion - it gets the build past that hurdle.
My bad that I had not looked more carefully at configure --help output.
But that brings back another 'issue' I had also seen when verifying 2.7.10. I
shall look in the bug-list for a related issue (I
Michael Felt added the comment:
At first I thought it might be a 0x0001 rather than 0x0003 (as I have no idea
what the additional info is AND that the lines starting with [0] are the Symbol
0 (zero) you indicate the message.
Also thought it might have been the double listing of some symbols
Michael Felt added the comment:
Since you are looking, maybe look at whether it is also libreSSL compatible?
--
nosy: +Michael.Felt
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Michael Felt <aixto...@gmail.com>:
--
title: cannot build python 2.7.11 on AIX -> could not build python 2.7.11 on AIX
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Michael Felt added the comment:
Would just like to add my heartfelt thanks for the simple hint
And, perhaps something to add to the Docs
After adding "--without-computed-gotos" I can complete a (default) configure,
make, make (DESTDIR=xxx) install of
* python-2.7.11 (was
New submission from Michael Felt:
Finally noticed the new release, unfortunately it fails to build.
All proceeds normally until...
tail .buildaix/make.out
ar rc libpython2.7.a Parser/acceler.o Parser/grammar1.o Parser/listnode.o
Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o
Michael Felt added the comment:
It worked fine using xlc with 2.7.10 (verified again today).
The delta between ceval.c in 2.7.10 and 2.7.11 is large.
make.out (excerpt) 2.7.10:
rm -f libpython2.7.a
ar rc libpython2.7.a Modules/getbuildinfo.o
ar rc libpython2.7.a Parser
Michael Felt added the comment:
If you need assistance (re: AIX), just ask.
However, I am guessing you have enough to move forward.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Michael Felt added the comment:
while reading to learn...
FYI: AIX does not return even a hint of the underlying platform (assumption is
probably 64-bit) - but the value of the interpreter is anyone's guess
root@x064:[/data/prj/aixtools/python/python-2.7.10]python
Python 2.7.10 (default, Mar
Michael Felt added the comment:
Patched to fp22: vacpp.11.1.0.22.aix53TL7-71.sept2015.ptf.tar.Z
after reinstalling system! to be sure no garbage left around.
Only updates are openSSL/SSH packages; no RPM's installed.
Same error message(s).
Tried compiling ceval.o with -O0 (capt. O, zero
Michael Felt added the comment:
These are very different issues. However, this patch may resolve both!
ldconfig (-p if I recall) lists where (shared) libraries have been installed
(imho, this is a GNU tool approach) - whereas AIX would use dump -H to find
library paths embedded in a program
Michael Felt added the comment:
Question - before I submit a patch.
A. Is there a PEP I should read re: ctypes/util and/or ctypes/cdll?
B. I show two different behaviors of responding - My question is, what does the
community think should be the response? My preference is to bring the request
Michael Felt added the comment:
I have not looked specifically, at least not that I remember, for differences
in util/ctypes in python2 and python3. Will do so tomorrow.
I did just look briefly at the library, rather archive, built by default as
libpython2.7.a - it is static members only, i.e
Michael Felt added the comment:
A bug was found, and has been corrected - but I am unclear on how to best
submit the differences.
Editing the current "review" code is not a good idea, as there are many
differences.
Please recommend correct course of action.
p.s. I will have al
Michael Felt added the comment:
a) https://bugs.python.org/review/26439/#msg12, but getting HTML 500 error)
The call to find_library here is for "ease of use" with existing code who use,
e.g., cdll("libcrypto.so"). This format fails unless someone has previously
done, e.
Michael Felt added the comment:
used diff -rNu Python-3.5.1 Python-3.5.1.1 to generate
--
Added file: http://bugs.python.org/file42811/Python3.issue26439.160511.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Michael Felt added the comment:
used diff -rNu Python-2.7.11 Python-2.7.11.4 to generate
Note: content same as those from yesterday - except
Lib/ctype/test/test_loading.py is no longer changed. No longer needed.
--
Added file: http://bugs.python.org/file42812/Python2.issue26439.160511
Michael Felt added the comment:
re:
AIX: CDLL("libcrypto.a(libcrypto.so.1.0.0)", DEFAULT_MODE | RTLD_MEMBER)
Officially it would be
dlopen("libcrypto.a(libcrypto.so.1.0.0)", RTLD_NOW | RTLD_MEMBER)
Further, that would only load the 32-bit version, as there is a l
Changes by Michael Felt <aixto...@gmail.com>:
Added file:
http://bugs.python.org/file42805/Python3.Modules._ctypes.160510.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Michael Felt <aixto...@gmail.com>:
Added file:
http://bugs.python.org/file42803/Python2.Modules._ctypes.160510.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Michael Felt <aixto...@gmail.com>:
Added file: http://bugs.python.org/file42804/Python3.Lib.ctypes.160510.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Michael Felt <aixto...@gmail.com>:
Added file: http://bugs.python.org/file42802/Python2.Lib.ctypes.160510.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Michael Felt added the comment:
Spent more time today, testing - on 3.5.1, 3.4.4 and 2.7.11.
The patches would not apply on both Python2 and Python3, but the new file
Lib/ctypes/aixutil.py is identical on all three versions.
History of patching (starting from version 3.5.1(.1) is my patched
Michael Felt added the comment:
In https://bugs.python.org/issue26439 I have been working on this for AIX - as
the default behavior was to depend on two things:
a) ldconfig -p (which generally does not exist on AIX, and I doubt it will know
about the non-gnu libraries
b) that the objects
Michael Felt added the comment:
On 4/28/2016 11:56 PM, Michael Felt wrote:
> Michael Felt added the comment:
>
> I have not looked specifically, at least not that I remember, for differences
> in util/ctypes in python2 and python3. Will do so tomorrow.
>
> I did just look brie
Michael Felt added the comment:
I cannot comment on uuid directly, but for me, this is yet another example of
how assumptions can break things.
imho - if you know the exact version of s shared library that you want, calling
cdll directly should be find. Maybe find_library is historic
Michael Felt added the comment:
reworked patch. To assist port to Python3 that changes in __init__.py and
util.py are minimal. There is a new file: aixutil.py
I have only tested on Python-2.7, so there may be issues for Python3. My goal
is to have a single file for both versions.
The main
Michael Felt added the comment:
implements ctypes.aixutil.find_library()
In a separate file as both __init__.py as util.py needs it's logic.
--
Added file: http://bugs.python.org/file42713/aixutil.py
___
Python tracker <rep...@bugs.python.org>
Michael Felt added the comment:
New patch of the Lib/ctypes directory - BUT - this time as a delta based on
3.5.0.
++ changes from last patch ++
* OSError gets raised (as expected) by test/test_loading.py
* test in util.py modified (libm is replaced by libc when "aix"), and
added an
Michael Felt added the comment:
New version of aixutil.py
++ Changes ++
* more comments
* re-worked the 'searches' for matches after adding changing the way
the output from _get_dumpH was read (now to an array using readlines).
Also, p.stdout.close() and p.wait() are done within the _get_dumpH
Michael Felt added the comment:
hmm. needs patch. For what?
One comment says a change will be undone.
If a patch is expected for src/builddir issue:
a) I sinned - that is a new issue, and should be posted seperately.
b) i do not know autotools well enough to solve the srcdir and builddir
New submission from Michael Felt:
Note: - Only examined on Python 2.7, but expect the same issue (from Python
3.4.X, 3.5.X and 3.6.X based on earlier attempts to use a separate builddir
SUMMARY:
* when builddir==srcdir build completes normally, (see DETAILS2:)
* when builddir!=srcdir
Michael Felt added the comment:
An interesting read, but I am lost in what the goal is.
e.g., on AIX, which I know well, the system default is /bin/ksh (aka
/usr/bin/ksh). However, /bin/sh (/usr/bin/sh) is available as well.
My expectation is that on Linux the default shell is /bin/bash
Michael Felt added the comment:
Seems to be okay at least with Python 3.6 "test" version - but maybe there is
better way to call these tests - just to be sure the one needed is not being
skipped.
On AIX 5.3 TL7 SP0:
root@x064:[/data/prj/aixtools/python/python-3.6.0.162/Lib/test]..
Michael Felt added the comment:
FYI: this seems to still be current, although issue11193 seems okay.
michael@x071:[/data/prj/aixtools/python/python-3.6.0.162/Lib/test]../../python
test_locale.py
..testing with 'en_US.ISO8859-1'... .testing with
'en_US.ISO8859-1'... Ftesting
Michael Felt added the comment:
FYI: test fails on AIX 5.3 TL7 SP0 (as expected. The IBM document refers to 5.3
TL8)
On AIX 6.1 TL9 SP5 (and probably earlier) the test passes. IMHO - can be closed
(and README.AIX can be updated).
michael@x071:[/data/prj/aixtools/python/python-2.7.11.5/Lib
Michael Felt added the comment:
Adding "type behavior" as I have now read that that is actually the python
friendly way of talking about a 'bug'.
Testing my proposed patch for 2.7 with python2.7.12 - will update with patch
when finished.
--
nosy: +Michael.Felt
type: -
Michael Felt added the comment:
Getting back to this summary:
Windows: {name} and {name}.dll, via %PATH%
OS X: lib{name}.dylib, {name}.dylib and {name}.framework/{name}, via dyld_find()
BSD: lib{name}.* via ldconfig (choose highest ABI version) and cc
Solaris: lib{name}.so via crle, and lib{name
Michael Felt added the comment:
FYI: similar (exact) results when 64-bit mode:
root@x064:[/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test]../../../python
./runtests.py
A 0x1001f 0
B 0x2001d 0
C 0x3001a 0
D 0x40016 0
E 0x50011 0
F 0x6000b 0
G 0x70004 0
H 0x80018 4
I 0x9000f 4
M 0x1000e
New submission from Michael Felt:
I am preparing a system with gcc to see if it is compiler related, i.e., goes
away with gcc. On the one hand, fingers crossed - but on the other, having
bitfields working regardless of the compiler should be preferred.
This issue is similar to a Solaris (C
Michael Felt added the comment:
So, it seems to be a compiler issue - when built using gcc (v4.7.4) the tests
take a bit longer, but no failures.
root@x065:[/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test]../../../python
runtests.py
A 0x1001f 0
B 0x2001d 0
C 0x3001a 0
D 0x40016 0
E
Michael Felt added the comment:
imho - it is not correct to only make a modification of this nature for a
single platform.
To be realistic, if the "design" goal is to 'find' what dlopen() will find when
given a argument without a pathname component - then gcc should not be used,
a
Michael Felt added the comment:
Vinay - I am in favor, but if the root cause of the holdup is unclear
documentation then let's address the root cause.
Stronger, I am in agreement. The first patch I submitted for AIX included using
LIBPATH (and could have added LD_LIBRARY_PATH
Michael Felt added the comment:
"""
Lib/ctype support for LoadLibrary interface to dlopen() for AIX
Similar kind of support (i.e., as a separate file)
as has been done for Darwin support ctype.macholib.*
rather than as been done with for "ce", "nt", "sol
Michael Felt added the comment:
> I presume this also affects Python 3.
I presume this as well - however, harder to verify...
michael@x071:[/data/prj/aixtools/python/python-3.6.0.162/Lib/ctypes/test]../../../python
test_bitfield.py
Could not find platform dependent libraries
Consider sett
Michael Felt added the comment:
FYI - after a couple of test compiles, it seems that IBM XLC does not report a
message when the size specified is int, unsigned or long (i.e., does not like
short).
Are you interested in the results using a size other than short - or would that
break something
Michael Felt added the comment:
Yes, clearly related (maybe even duplicate).
What surprised me is that after I copied ld_so_aix to where it was expected I
still see a premature end with:
Traceback (most recent call last):
File "/var/aixtools/python/Python/2.7.12.0/opt/lib/pyth
Michael Felt added the comment:
> FYI: I tried to pip install Mercurial - but got an error message from an
> include file so the last bit did not compile. Problem for a later date -
> could be a user error on my part, or an AIX version dependency. (during
> discussion issue26
Michael Felt added the comment:
Thanks again for your help.
Note: I started a issue# is because too much of what I was submitting here was
"extension" and not "correction".
Hopefully, the new issue# will be cleaner.
--
___
Michael Felt added the comment:
Had some flooding (leaking pipes, rather values) issues to fix. Will
look at this asap.
On 04-Aug-16 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,
&
Michael Felt added the comment:
On 02-Aug-16 15:34, Martin Panter wrote:
> Martin Panter added the comment:
>
> For 2.7, adding the automatic RTLD_MEMBER mode does not seem like a bug fix
> to me. Currently, I understand this code could load two separate libraries:
>
> file =
Michael Felt added the comment:
On 8/4/2016 10:58 AM, Martin Panter wrote:
> Can you figure out a way to test for XLC (but not GCC, which the AIX buildbot
> uses), and then try my patch out? Hopefully you see no more compiler
> warnings, test_ints() should now pass, and test_shorts
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 "
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
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
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
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
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
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
Michael Felt added the comment:
The more common TESTED "behavior" issue is simply:
find_library("c") always returns None while it should be returning
either libc.a(shr.o) in 32-bit mode and libc.a(shr_64.o) in 64-bit mode.
If that gets corrected, then adding RTLD_M
Michael Felt added the comment:
I'll get to this asap. Have to install a new "clean" environment aka a
new virtual machine.
On 18-Aug-16 02:43, Martin Panter wrote:
> Martin Panter added the comment:
>
> Michael, byref() is just a helper for passing an object’s address
New submission from Michael Felt:
FYI: Compiler warnings that appear on stderr (skipping any messages sent to
stdout) - xlc V11 as the reporting compiler.
Two that may need attention are the redefines of _POSIX_C_SOURCE and
_XOPEN_SOURCE in pyconfig.h
Also surprised by the message:
Could
New submission from Michael Felt:
p.s. - guessing on the component - this is after make install
+ make install DESTDIR=/var/aixtools/aixtools/python/3.6.0.164 >
.buildaix/install.out
+ mkinstallp.ksh /var/aixtools/aixtools/python/3.6.0.164 >
.buildaix/mkinstallp.out
+
renamed:./o
Michael Felt added the comment:
On 23-Aug-16 19:02, R. David Murray wrote:
> R. David Murray added the comment:
>
> setuptools is not part of CPython or the standard library, though it is
> currently distributed with CPython via ensurepip. You should report this
> issue to
Michael Felt added the comment:
On 04/09/2016 06:11, Martin Panter wrote:
> I do not know whether to fix the annotation (has 64 preceded by any number of
> underscores), or whether to fix the regular expression (_?64).
The later - _?64. Working on this today. Thank you for the corr
Michael Felt added the comment:
Not always as elegant as I would wish (do not like the idea of "while 1:" and
later a break...
But, all in all, much improved by redoing the processing of the subprocess
output and getting rid of more noise.
Hope this meets your approval!
p.s. This
Michael Felt added the comment:
re: issue 26439 and issue 27435 would like to show:
without patch, find_library() is consistently slow, and in default situations,
returns nothing.
root@x064:[/data/prj/aixtools/python/python-2.7.10]./python -m timeit -n 100
'import ctypes.util
New submission from Michael Felt:
Short version:
the five routines get_node() calls to get the MAC address either fail by
definition, or is wrong.
The one routine that works - is wrong because it returns the same value
regardless of the system it runs on - wrong character is used to identify
Michael Felt added the comment:
On 27-Aug-16 09:11, Martin Panter wrote:
> Martin Panter added the comment:
>
> The documentation is in RST format in the Doc/ directory. For basic stuff,
> you can just copy the syntax from existing text, or see e.g.
> <https://docs.p
Michael Felt added the comment:
Sigh - missed the feature cutoff that would have made this easier to get into
python...
Anyway - have learned a few new things about python def: syntax and removed
some bits that I thought were suitable for variable "initialization" - but tend
to
New submission from Michael Felt:
I was asked to assist with some problems with a "pip install numpy" and - maybe
I am barking up the wrong tree. However, in the thread
https://github.com/numpy/numpy/issues/8118
in short, if "python" is responsible for providing the
Michael Felt added the comment:
I have spent the last two hours trying to run the test - however, it fails with:
root@x064:[/data/prj/python/python-3.6.0.177/Lib/ctypes]../../python util.py
Traceback (most recent call last):
File "util.py", line 102, in
import ctypes._aix as
Michael Felt added the comment:
Have a way to have both 64-bit and 32-bit modes working.
root@x064:[/data/prj/python/python-3.6.0.177/Lib/ctypes]../../python
`pwd`/util.py
m :: None
c :: libc.a(shr_64.o)
bz2 :: libbz2.a(libbz2.so.1)
crypt :: libcrypt.a(shr_64.o)
crypto ::
c
Michael Felt added the comment:
Curious.
When in 32-bit mode changing line 15 of _aix.py to
+14 import re, os, sys
+15 # from . import util
The Lib/ctypes/util.py works.
In 64-bit mode it does not:
instead:
root@x064:[/data/prj/python/python-3.6.0.177/Lib/ctypes]../../python util.py
Michael Felt added the comment:
On 01-Oct-16 08:44, Martin Panter wrote:
> Martin Panter added the comment:
>
> Hi Michael, I have done some cleanup and modifications to your patch. The
> result is in aix-library.161001.patch, which has all the changes, i.e. it is
> not based o
1 - 100 of 737 matches
Mail list logo
