Date: Mon, 2 May 2005 00:05:18 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 546 ************************************************** Sunday 01 May 2005 Number 546 ************************************************** Subjects for today 1 Re: Anyone know what this means? : Thomas Dickey 2 Re: Anyone know what this means? : lsunley at mb.sympatico.ca 3 Re: Anyone know what this means? : Knut St. Osmundsen" 4 Updated Python Build 20050501 : Paul Smedley 5 Request for Comment: Patches for Innotek GCC & Python : Paul Smedley 1 Re: Anyone know what this means? : Paul Smedley 6 Re: Request for Comment: Patches for Innotek GCC & Python : Andrew MacIntyre **= Email 1 ==========================** Date: Sat, 30 Apr 2005 09:58:49 -0400 (EDT) From: Thomas Dickey Subject: Re: Anyone know what this means? On Sat, 30 Apr 2005, Paul Smedley wrote: > Just noticed the following in the build logs of Python 2.4.1 when I include > ncurses support: > > Creating .DEF file: out/optimize/_curses_m.def > gcc -Zmt -Zcrtdll -L. -lgcc -s -Zomf -Zdll -o _curses.dll > out/optimize/_cursesmo > dule.obj out/optimize/_curses_m.def -lpython24 -lsocket -lncurses > weakld: E:/DEV/Python-2.4.1/PC/os2emx/out/optimize/_curses_m.def - error: > Parse > error 2 on line 9. (errorcode=7 stmt=1177112) > weakld: error: Parse error 2 on line 9. (errorcode=7 stmt=0) > > > Anyone know what the above parse errors mean? perhaps line 8 was a little too long for the linker? > > _curses_m.def is as follows: > LIBRARY _curses_m INITINSTANCE TERMINSTANCE > DESCRIPTION "" > DATA MULTIPLE NONSHARED > EXPORTS > _init_curses > _wnoutrefresh > __nc_panelhook > _is_linetouched > _mvwin > _stdscr > _wtouchln > > > Cheers, > > Paul. > -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 2 ==========================** Date: Sat, 30 Apr 2005 12:15:18 -0500 From: lsunley at mb.sympatico.ca Subject: Re: Anyone know what this means? Do you have ILINK 5.0? In <20050430095755.L62033 at mail.his.com>, on 04/30/05 at 09:58 AM, Thomas Dickey said: >On Sat, 30 Apr 2005, Paul Smedley wrote: >> Just noticed the following in the build logs of Python 2.4.1 when I include >> ncurses support: >> >> Creating .DEF file: out/optimize/_curses_m.def >> gcc -Zmt -Zcrtdll -L. -lgcc -s -Zomf -Zdll -o _curses.dll >> out/optimize/_cursesmo >> dule.obj out/optimize/_curses_m.def -lpython24 -lsocket -lncurses >> weakld: E:/DEV/Python-2.4.1/PC/os2emx/out/optimize/_curses_m.def - error: >> Parse >> error 2 on line 9. (errorcode=7 stmt=1177112) >> weakld: error: Parse error 2 on line 9. (errorcode=7 stmt=0) >> >> >> Anyone know what the above parse errors mean? >perhaps line 8 was a little too long for the linker? >> >> _curses_m.def is as follows: >> LIBRARY _curses_m INITINSTANCE TERMINSTANCE >> DESCRIPTION "" >> DATA MULTIPLE NONSHARED >> EXPORTS >> _init_curses >> _wnoutrefresh >> __nc_panelhook >> _is_linetouched >> _mvwin >> _stdscr >> _wtouchln >> >> >> Cheers, >> >> Paul. >> -- ----------------------------------------------------------- lsunley at mb.sympatico.ca ----------------------------------------------------------- **= Email 3 ==========================** Date: Sat, 30 Apr 2005 19:36:49 +0200 From: "Knut St. Osmundsen" Subject: Re: Anyone know what this means? Paul Smedley wrote: > Just noticed the following in the build logs of Python 2.4.1 when I > include ncurses support: > > Creating .DEF file: out/optimize/_curses_m.def > gcc -Zmt -Zcrtdll -L. -lgcc -s -Zomf -Zdll -o _curses.dll > out/optimize/_cursesmo > dule.obj out/optimize/_curses_m.def -lpython24 -lsocket -lncurses > weakld: E:/DEV/Python-2.4.1/PC/os2emx/out/optimize/_curses_m.def - > error: Parse > error 2 on line 9. (errorcode=7 stmt=1177112) > weakld: error: Parse error 2 on line 9. (errorcode=7 stmt=0) > > > Anyone know what the above parse errors mean? Yes, it means that there is a parse error on line 2, the error code is 2 and the statement is a _MD_DESCRIPTION. It means that it didn't like "" as description. However this isn't illegal I think, so I've changed libmoddef (which is what weakld uses) to allow this. (I've also corrected the error messages which had mixed up arguments.) The code will be synced to netlabs on Monday I hope. In the mean time comment out the DESCRIPTION line (comment character is ';' for .def files). Kind Regards, knut > _curses_m.def is as follows: > LIBRARY _curses_m INITINSTANCE TERMINSTANCE > DESCRIPTION "" > DATA MULTIPLE NONSHARED > EXPORTS > _init_curses > _wnoutrefresh > __nc_panelhook > _is_linetouched > _mvwin > _stdscr > _wtouchln > > > Cheers, > > Paul. > **= Email 4 ==========================** Date: Sun, 01 May 2005 20:09:14 +0930 From: Paul Smedley Subject: Updated Python Build 20050501 Hi All, I've again updated the Python build - a new build can be found at http://smedley.info/python241-os2-innotekgcc20050501.zip The major change in this build is that I've made the necessary changes for large file (ie >2gb) support. There are now some known issues based on feedback from users: 1) Bittorrent v4.0 or higher is not working due to problems with ncurses support. 2) Bittorrent v3.4.2 shows some error messages at startup (in common with the EMX Python 2.4.1 build) however does download OK. Again, as I have limited upstream, please only download this if you intend testing. Once it is stabilised, I'll upload to Hobbes. Cheers, Paul. **= Email 5 ==========================** Date: Sun, 01 May 2005 20:27:59 +0930 From: Paul Smedley Subject: Request for Comment: Patches for Innotek GCC & Python Hi All, Currently, Python uses the following identifiers for OS/2... #if defined(PYOS_OS2) && defined(PYCC_GCC) & presumably there's still some in there for PYCC_VACPP. This works fine - however requires specific #define entries in pyconfig.h and would require changes to configure if we're ever going to get a build that will compile using: ./configure make Shouldn't using the identifiers: __EMX__ for EMX & __INNOTEK_LIBC__ for Innotek GCC be a better way to go? Looking back at Dave's email from the other day this is exactly what he's suggesting... ../configure does generate a fairly decent pyconfig.h for Innotek GCC - however doesn't compile due to the reliance on the definition of PYOS_OS2 & PYCC_GCC Andy - pretty interested in your thoughts on this. I'm happy to generate all the required patches.... Cheers, Paul. **= Email 1 ==========================** Date: Sun, 01 May 2005 10:06:30 +0930 From: Paul Smedley Subject: Re: Anyone know what this means? Hiya Knut, >> Anyone know what the above parse errors mean? > > > Yes, it means that there is a parse error on line 2, the error code is 2 > and the statement is a _MD_DESCRIPTION. > > It means that it didn't like "" as description. However this isn't > illegal I think, so I've changed libmoddef (which is what weakld uses) > to allow this. (I've also corrected the error messages which had mixed > up arguments.) > > The code will be synced to netlabs on Monday I hope. In the mean time > comment out the DESCRIPTION line (comment character is ';' for .def files). Thanks. I was hoping that the above was the reason for problems with ncurses and bittorrent 4.0 with Python but turns out it was wishful thinking :( Python is compiling and linking fine with ncurses support, but on running bittorrent 4.0 I'm getting: Traceback (most recent call last): File "btdownloadcurses.py", line 421, in ? curses_wrapper(dl.run) File "E:/PYTEMP/Lib/curses/wrapper.py", line 49, in wrapper curses.nocbreak() _curses.error: nocbreak() returned ERR hmmm wonder if underscores are needed when calling items in curses.lib and that's my problem..... Cheers, Paul. **= Email 6 ==========================** Date: Sun, 01 May 2005 23:21:35 +1100 From: Andrew MacIntyre Subject: Re: Request for Comment: Patches for Innotek GCC & Python Paul Smedley wrote: > Hi All, > Currently, Python uses the following identifiers for OS/2... > > #if defined(PYOS_OS2) && defined(PYCC_GCC) > > & presumably there's still some in there for PYCC_VACPP. > > This works fine - however requires specific #define entries in > pyconfig.h and would require changes to configure if we're ever going to > get a build that will compile using: > ./configure > make > > Shouldn't using the identifiers: > __EMX__ for EMX > & > __INNOTEK_LIBC__ for Innotek GCC be a better way to go? > > Looking back at Dave's email from the other day this is exactly what > he's suggesting... > > ./configure does generate a fairly decent pyconfig.h for Innotek GCC - > however doesn't compile due to the reliance on the definition of > PYOS_OS2 & PYCC_GCC > > Andy - pretty interested in your thoughts on this. I'm happy to > generate all the required patches.... First up, let me thank you for picking up the baton for getting Python working with the Innotek toolchain. Now, some guidelines that I (as a Python CVS commit privileges holder) have to live by: - bug fixes only on the current stable branch (ie 2.4.x); - support for new platforms (on past history, a diffent compiler/libc vendor counts as a platform in Python's CVS) have to go into the head branch (ie 2.5 to be); - if you want to use ./configure, setup.py has to work to build the optional extensions. This means that Distutils support for the Innotek toolchain will be needed where usage differs from EMX. The first two are enforced by the Python release manager, and he won't budge easily. This means it is most unlikely your changes can be rolled into the Python 2.4 branch :-(, though when you have a patchkit I can ask the RM whether he'll buy it. Now some guidelines for what I'm prepared to go forward with into the head branch: - I plan to keep the VAC++ support for the time being, likewise I plan to maintain the EMX port for some time; - on past experience, I am risk averse to a large scale change of #defines; - on principle, I don't like to rely on __EMX__ because it was supported on DOS & NT (even though I doubt you'd find it today); - similarly, I'm wary of sprinkling __INNOTEK_LIBC__ throughout the whole codebase, especially where the EMX code is shared; - I have freedom to make any changes I please in Lib/plat-os2emx as well as PC/os2emx (& PC/os2vacpp FWIW); - I can/will apply source patches that add the necessary support (provided I can test or verify them); - Because of the sensitivity of the stability of the configure infrastucture, I will not apply any patches to configure.in or pyconfig.in myself but instead post a patch to the tracker and request review and application by another developer; - Python must survive the regression test with no critical failures, either with Innotek or EMX, or any other system I can test on (usually FreeBSD). Therefore, unless someone can convince me to do otherwise, my approach will be: 1) continue using the PYOS_OS2 define to denote an OS/2 based platform with PYOS_VACPP indicating the VAC++ toolchain 2) maintain PYCC_GCC=1 to indicate the EMX port, using PC/os2emx/pyconfig.h 3) use PYCC_GCC=2 to indicate __INNOTEK_LIBC__ with the transformation being handled in the configure machinery (which also adds the PYOS_OS2 definition) - differences from EMX can be then handled as #if defined(PYOS_OS2) && defined(PYCC_GCC) #if PYCC_GCC > 1 ... /* Innotek */ #else ... /* EMX */ #endif #endif 4) The EMX port build infrastructure will be maintained 5) The Innotek toolchain source changes be made using 3 above 6) as an interim measure, an Innotek specific makefile & pyconfig.h be added to the EMX port directory pending the configure support (to allow building/testing) 7) I post the configure machinery changes for review/application by another Python developer; with configure defining PYOS_OS2 and PYCC_GCC=2 I hope that the patches you generate can be used within this framework with the minimum of hassle. Regards, Andrew. ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac at pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia