What's required to keep OS/2 support in Python 3.3
Hi All, I'm a little slow in responding to http://blog.python.org/2011/05/python-33-to-drop-support-for-os2.html, but I'm interested in stepping up to help maintain OS/2 support in Python 3.3 and above. I've been building Python 2.x for a while, and currently have binaries of 2.6.5 available from http://os2ports.smedley.info Unlike Andrew Mcintyre, I'm using libc for development (http://svn.netlabs.org/libc) rather than emx. libc is still being developed whereas emx hasn't been updated in about 10 years. I haven't attempted a build of 3.x yet, but will grab the latest 3.x release and see what it takes to get it building here. I expect I'll hit the same problem with sysconfig.get_config_var("CONFIG_ARGS"): as with 2.7.2 but we'll wait and see. Cheers, Paul
Hi Paul,
I'm a little slow in responding to http://blog.python.org/2011/05/python-33-to-drop-support-for-os2.html, but I'm interested in stepping up to help maintain OS/2 support in Python 3.3 and above.
I've been building Python 2.x for a while, and currently have binaries of 2.6.5 available from http://os2ports.smedley.info
Unlike Andrew Mcintyre, I'm using libc for development (http://svn.netlabs.org/libc) rather than emx. libc is still being developed whereas emx hasn't been updated in about 10 years.
I haven't attempted a build of 3.x yet, but will grab the latest 3.x release and see what it takes to get it building here.
I would suggest you start from the Mercurial repository instead. There you'll find both the current stable branch (named "3.2") and the current development branch (named "default"). It will also make it easier for you to write and maintain patches. Let me point you to the devguide, even though it doesn't talk specifically about porting: http://docs.python.org/devguide/ Regards Antoine.
Hi All, On 06/01/12 19:22, Paul Smedley wrote:
I'm a little slow in responding to http://blog.python.org/2011/05/python-33-to-drop-support-for-os2.html, but I'm interested in stepping up to help maintain OS/2 support in Python 3.3 and above.
I've been building Python 2.x for a while, and currently have binaries of 2.6.5 available from http://os2ports.smedley.info
Unlike Andrew Mcintyre, I'm using libc for development (http://svn.netlabs.org/libc) rather than emx. libc is still being developed whereas emx hasn't been updated in about 10 years.
I haven't attempted a build of 3.x yet, but will grab the latest 3.x release and see what it takes to get it building here. I expect I'll hit the same problem with sysconfig.get_config_var("CONFIG_ARGS"): as with 2.7.2 but we'll wait and see.
I now have a dll and exe - however when it tried to build the modules,
it dies with:
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries
On Sat, 07 Jan 2012 06:28:00 +1030
Paul Smedley
I now have a dll and exe - however when it tried to build the modules, it dies with: Could not find platform independent libraries <prefix> Could not find platform dependent libraries
Consider setting $PYTHONHOME to <prefix>[: ] Fatal Python error: Py_Initialize: Unable to get the locale encoding
I would look at this line:
LookupError: no codec search functions registered: can't find encoding
Normally the standard codec search function is registered when importing the "encodings" module (see Lib/encodings/__init__.py), which is done at the end of _PyCodecRegistry_Init() in Python/codecs.c. There's this comment there: /* Ignore ImportErrors... this is done so that distributions can disable the encodings package. Note that other errors are not masked, e.g. SystemErrors raised to inform the user of an error in the Python configuration are still reported back to the user. */ For the purpose of debugging you could *not* ignore the error and instead print it out or bail out. Regards Antoine.
Hi Antoine, On 07/01/12 06:58, Antoine Pitrou wrote:
On Sat, 07 Jan 2012 06:28:00 +1030 Paul Smedley
wrote: I now have a dll and exe - however when it tried to build the modules, it dies with: Could not find platform independent libraries<prefix> Could not find platform dependent libraries
Consider setting $PYTHONHOME to<prefix>[: ] Fatal Python error: Py_Initialize: Unable to get the locale encoding I would look at this line:
LookupError: no codec search functions registered: can't find encoding
Normally the standard codec search function is registered when importing the "encodings" module (see Lib/encodings/__init__.py), which is done at the end of _PyCodecRegistry_Init() in Python/codecs.c. There's this comment there:
/* Ignore ImportErrors... this is done so that distributions can disable the encodings package. Note that other errors are not masked, e.g. SystemErrors raised to inform the user of an error in the Python configuration are still reported back to the user. */
For the purpose of debugging you could *not* ignore the error and instead print it out or bail out. Thanks - commenting out the ImportErrors block, I get: ImportError: No module named encodings
So seems it's not finding modules - possibly related to the warnings about:
Could not find platform independent libraries<prefix> Could not find platform dependent libraries
Seems getenv() may not be working correctly...
On 07/01/12 08:22, Paul Smedley wrote:
For the purpose of debugging you could *not* ignore the error and instead print it out or bail out. Thanks - commenting out the ImportErrors block, I get: ImportError: No module named encodings
OK got through this - PYTHONPATH in makefile was borked for OS/2 (: separators vs ; which don't work so well with drive letters) Now having trouble importing the _io module even though it's builtin <sigh>
On 08/01/12 19:07, Paul Smedley wrote:
On 07/01/12 08:22, Paul Smedley wrote:
For the purpose of debugging you could *not* ignore the error and instead print it out or bail out. Thanks - commenting out the ImportErrors block, I get: ImportError: No module named encodings
OK got through this - PYTHONPATH in makefile was borked for OS/2 (: separators vs ; which don't work so well with drive letters)
Now having trouble importing the _io module even though it's builtin <sigh>
to be clear, the error is: Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "U:/DEV/python-3.2.2/Lib/io.py", line 60, in <module> Killed by SIGABRT
On 08/01/12 19:12, Paul Smedley wrote:
On 08/01/12 19:07, Paul Smedley wrote:
On 07/01/12 08:22, Paul Smedley wrote:
For the purpose of debugging you could *not* ignore the error and instead print it out or bail out. Thanks - commenting out the ImportErrors block, I get: ImportError: No module named encodings
OK got through this - PYTHONPATH in makefile was borked for OS/2 (: separators vs ; which don't work so well with drive letters)
Now having trouble importing the _io module even though it's builtin <sigh>
to be clear, the error is: Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "U:/DEV/python-3.2.2/Lib/io.py", line 60, in <module>
Killed by SIGABRT
and it's dying in _iomodule.c at: /* put os in the module state */ state->os_module = PyImport_ImportModule("os"); if (state->os_module == NULL){ fprintf(stderr,"_iomodule fail\n"); goto fail;} for some reason.. at least I'm slowly making progress :P (I think) Cheers, Paul
participants (2)
-
Antoine Pitrou
-
Paul Smedley