Date: Thu, 5 May 2005 00:05:16 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 549 ************************************************** Wednesday 04 May 2005 Number 549 ************************************************** Subjects for today 1 Re: Innotek GCC & Python : Andrew MacIntyre 2 Re: Innotek GCC & Python : Paul Smedley 3 Re: Innotek GCC & Python : Paul Smedley" 4 Re: Innotek GCC & Python : Paul Smedley 5 Re: Innotek GCC & Python : Andrew MacIntyre **= Email 1 ==========================** Date: Tue, 03 May 2005 23:18:38 +1100 From: Andrew MacIntyre Subject: Re: Innotek GCC & Python Paul Smedley wrote: > patches sent to Andy off-list. Thanks. {...} > conventions... The part I don't yet understand is why the pyds (which > are renamed OS/2 DLLs) work but it appears at least that loading > _curses.dll doesn't... {...} >> The only Python curses code that I can think of, other than BitTorrent, >> is a demo version of Conway's Life in the psyco package; there is also >> a curses test in Python's regression test suite which might be worth a >> try (though I don't recall it working correctly when I tried it). >> > Curses test has a similar error to bittorrent..... Hmmm... Try renaming _curses.dll to _curses.pyd and re-run the curses regression test. The only reason for _curses to use the .dll extension rather than .pyd is so that the exported symbols (see the .def file) work with the curses.panel component (which is _curses_.pyd). BitTorrent's curses based downloader uses curses.panel, but the regression test doesn't try and test it. If _curses works as a .pyd (in the regression test), then we need to find out whether the implementation of dlopen() et al do something different based on the extension. are you using the dlfcn.c file in PC/os2emx, or a dlopen() in Innotek's libc? (NOTE: as per reply to your patch email, the makefile didn't get included in the patch) ------------------------------------------------------------------------- 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 **= Email 2 ==========================** Date: Wed, 04 May 2005 07:13:19 +0930 From: Paul Smedley Subject: Re: Innotek GCC & Python Hi Andy, Andrew MacIntyre wrote: > Hmmm... > > Try renaming _curses.dll to _curses.pyd and re-run the curses regression > test. Same error... with the regression test & bitttorrent > The only reason for _curses to use the .dll extension rather than .pyd > is so that the exported symbols (see the .def file) work with the > curses.panel component (which is _curses_.pyd). BitTorrent's curses > based downloader uses curses.panel, but the regression test doesn't > try and test it. > > If _curses works as a .pyd (in the regression test), then we need to > find out whether the implementation of dlopen() et al do something > different based on the extension. are you using the dlfcn.c file in > PC/os2emx, or a dlopen() in Innotek's libc? (NOTE: as per reply > to your patch email, the makefile didn't get included in the patch) I'm using your dlfcn.c in pc/os2emx.... Cheers, Paul. **= Email 3 ==========================** Date: Wed, 04 May 2005 08:32:34 +0930 From: "Paul Smedley" Subject: Re: Innotek GCC & Python Hi Again, On 3/5/2005, "Andrew MacIntyre" wrote: >Paul Smedley wrote: >If _curses works as a .pyd (in the regression test), then we need to >find out whether the implementation of dlopen() et al do something >different based on the extension. are you using the dlfcn.c file in >PC/os2emx, or a dlopen() in Innotek's libc? I think you're on the right track here. The pyconfig.h generated by configure sets the following that aren't present in your pyconfig.h: /* Define to 1 if you have the header file. */ #define HAVE_DLFCN_H 1 /* Define to 1 if you have the `dlopen' function. */ #define HAVE_DLOPEN 1 I must go through the ./configure generated pyconfig.h and our hand-coded one and see if there's anything else that can be set to yes for innotek libc. I'll try tonight removing dlfcn.c from the innotek makefile and see what happens. Thanks for the ideas :) Cheers, Paul. **= Email 4 ==========================** Date: Wed, 04 May 2005 19:44:42 +0930 From: Paul Smedley Subject: Re: Innotek GCC & Python Hi All, Paul Smedley wrote: > Hi Again, > > On 3/5/2005, "Andrew MacIntyre" wrote: >>Paul Smedley wrote: >>If _curses works as a .pyd (in the regression test), then we need to >>find out whether the implementation of dlopen() et al do something >>different based on the extension. are you using the dlfcn.c file in >>PC/os2emx, or a dlopen() in Innotek's libc? > > > I think you're on the right track here. > > The pyconfig.h generated by configure sets the following that aren't > present in your pyconfig.h: > /* Define to 1 if you have the header file. */ > #define HAVE_DLFCN_H 1 > > /* Define to 1 if you have the `dlopen' function. */ > #define HAVE_DLOPEN 1 > > I'll try tonight removing dlfcn.c from the innotek makefile and see what > happens. > > Thanks for the ideas :) Well I just did this - unfortunately no change in the behavior of curses support in Python.... I am getting the following warnings when compiling - but had ignored them thus far... .../../Modules/_cursesmodule.c -o out/optimize/_cursesmodule.obj .../../Modules/_cursesmodule.c: In function `PyCursesWindow_is_wintouched': .../../Modules/_cursesmodule.c:291: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:291: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:291: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:291: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c: In function `PyCursesWindow_Is_LineTouched': .../../Modules/_cursesmodule.c:1097: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1098: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1100: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1101: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c: In function `PyCurses_can_change_color': .../../Modules/_cursesmodule.c:1556: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1556: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1556: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1556: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c: In function `PyCurses_has_colors': .../../Modules/_cursesmodule.c:1557: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1557: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1557: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1557: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c: In function `PyCurses_has_ic': .../../Modules/_cursesmodule.c:1558: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1558: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1558: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1558: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c: In function `PyCurses_has_il': .../../Modules/_cursesmodule.c:1559: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1559: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1559: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1559: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c: In function `PyCurses_isendwin': .../../Modules/_cursesmodule.c:1560: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1560: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1560: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1560: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c: In function `PyCurses_has_key': .../../Modules/_cursesmodule.c:1728: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1729: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1731: warning: dereferencing type-punned pointer will break strict-aliasing rules .../../Modules/_cursesmodule.c:1732: warning: dereferencing type-punned pointer will break strict-aliasing rules Thoughts? Cheers, Paul. **= Email 5 ==========================** Date: Wed, 04 May 2005 22:20:08 +1100 From: Andrew MacIntyre Subject: Re: Innotek GCC & Python Paul Smedley wrote: >> The pyconfig.h generated by configure sets the following that aren't >> present in your pyconfig.h: >> /* Define to 1 if you have the header file. */ >> #define HAVE_DLFCN_H 1 >> >> /* Define to 1 if you have the `dlopen' function. */ >> #define HAVE_DLOPEN 1 These defines suggest that the Innotek libc has dlopen() so using it would be better than the version in dlfcn.c. >> I'll try tonight removing dlfcn.c from the innotek makefile and see what >> happens. >> >> Thanks for the ideas :) > > > Well I just did this - unfortunately no change in the behavior of curses > support in Python.... > > I am getting the following warnings when compiling - but had ignored > them thus far... > > ./../Modules/_cursesmodule.c -o out/optimize/_cursesmodule.obj > ./../Modules/_cursesmodule.c: In function `PyCursesWindow_is_wintouched': > ./../Modules/_cursesmodule.c:291: warning: dereferencing type-punned > pointer will break strict-aliasing rules does gcc 3.3.x support -fno-strict-aliasing? if so, add it to the CFLAGS make variable - change CFLAGS+= -s -O3 -fomit-frame-pointer -mprobe to CFLAGS+= -s -O3 -fomit-frame-pointer -mprobe -fno-strict-aliasing I quote from configure.in: "# Python violates C99 rules, by casting between incompatible # pointer types. GCC may generate bad code as a result of that, # so use -fno-strict-aliasing if supported." Whether this will change anything I don't know, but I have seen a couple of reports of it mattering on Linux. Sometimes I've found it worthwhile to drop the optimisation level from -O3 to -Os to see whether behaviour changes. ------------------------------------------------------------------------- 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