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:
* 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:
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:
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:
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:
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:
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:
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:
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:
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
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:
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
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/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/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/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:
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:
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:
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:
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:
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:
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:
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 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:
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:
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:
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
I have been packaging python for AIX - and wanting minimal dependancies
I have been ignoring the final messages from make.
Personally, I do not see any real harm in the missing *audio "bits", but
how terrible are the other missing "bits" for normal python programs?
Many thanks for feedback!
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:
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:
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
) patch.
Michael
p.s. the >>> prompts make it look very colorful in my mail program!
On 2016-03-04 11:22, Peter Otten wrote:
Michael Felt wrote:
First, a simple one:
sysconfig.is_python_build()
Return True if the current Python installation was built fr
First, a simple one:
sysconfig.is_python_build()
Return True if the current Python installation was built from source.
sysconfig.is_python_build()
False
Now, not earth shattering, but I did build this from source - so can someone
help me with understanding why Python says no?
FYI:
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
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
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:
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:
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:
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:
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:
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
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:
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:
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:
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:
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:
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
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:
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:
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:
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
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
701 - 756 of 756 matches
Mail list logo
