Date: Tue, 3 May 2005 00:05:20 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600
Subject: [UnixOS2_Archive] No. 547

**************************************************
Monday 02 May 2005
 Number  547
**************************************************

Subjects for today
 
1  Re:  Request for Comment: Patches for Innotek GCC & Python : Dave Yeo" <dave_yeo at paralynx.com>
2   Re:  Request for Comment: Patches for Innotek GCC & Python : Paul Smedley" <paul at smedley.info>
3  Re:  Updated Python Build 20050501 : Stefan.Neis at t-online.de
4  Re:  Updated Python Build 20050501 : Paul Smedley <paul at smedley.info>
5  Re:  Updated Python Build 20050501 : Stefan.Neis at t-online.de
6   Generating diffs : Paul Smedley <paul at smedley.info>
7  Re:  Re:  Request for Comment: Patches for Innotek GCC & Python : Stefan.Neis at t-online.de
8  Re:  Re:  Request for Comment: Patches for Innotek GCC & Python : Andrew MacIntyre <andymac at bullseye.apana.org.au>


**= Email   1 ==========================**

Date:  Sun, 01 May 2005 11:42:51 -0800
From:  "Dave Yeo" <dave_yeo at paralynx.com>
Subject:  Re:  Request for Comment: Patches for Innotek GCC & Python

On Sun, 01 May 2005 23:21:35 +1100, Andrew MacIntyre wrote:

>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

From Innoteks ReleaseNotes.os2
o GCC defines __INNOTEK_LIBC__=0x005.
   The value reflects the LIBC version, form: 0xGMM
   Where G=major version and MM=middle version numbers.

So PY_GCC could be defined to the Innotek libc version. This way could take care of 
things like the fact Innotek libc ver 5 does not do fork but ver 6 does. Also who knows 
what ever goodies Knut might add later.
Also I don't know if Python still compiles on GCC 2.8.1 or not but in the future it may not 
and the lower PY_GCC numbers could be used for differentiating between GCC 2.8.1 
and GCC 2.95.3 etc.
Dave 



**= Email   2 ==========================**

Date:  Mon, 02 May 2005 08:56:21 +0930
From:  "Paul Smedley" <paul at smedley.info>
Subject:   Re:  Request for Comment: Patches for Innotek GCC & Python

Hi Andy (& Others)

On 1/5/2005, "Andrew MacIntyre <andymac at bullseye.apana.org.au wrote:
>Paul Smedley wrote:
>> 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.
No problems - it's been a lot of fun :)

>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);
I'd already suspected this so did a CVS get of the 2.5 source last night
:)

>- 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.
I don't quite understand this yet but OK :)  I think using ./configure
is a longer term goal anyway.... configure needs changes at the very
least to define PYOS_OS2=1 & PYCC_GCC=1/2

>Now some guidelines for what I'm prepared to go forward with into the
>head branch:

<snip>

>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
I can live with this.  This should also work in pyconfig.h as there
really aren't that many changes, which means it will just be a
different makefile that is required.

>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)
As above - makefile should be the only required change in pc/os2emx

>7) I post the configure machinery changes for review/application by
>    another Python developer; with configure defining PYOS_OS2 and
>    PYCC_GCC=2
Once I figure out how to reliably test for Innotek using configure :)

>I hope that the patches you generate can be used within this
>framework with the minimum of hassle.

I don't see a problem - just wanted to discuss it before I went ahead
with anything :)

I'll hopefully get some patches to the 2.5 tree to get the Python-cvs to
the same point with Innotek GCC that I'm at with 2.4.1 - that is -
problems with curses & bittorrent 4.0 but everything else seems OK.

Thanks for your input!

Cheers,

Paul.


**= Email   3 ==========================**

Date:  Mon, 02 May 2005 12:16:14 +0200 (CEST)
From:  Stefan.Neis at t-online.de
Subject:  Re:  Updated Python Build 20050501

Paul Smedley schrieb:
>
> The major change in this build is that I've made the
> necessary changes 
> for large file (ie >2gb) support.

Any hints on what was actually required to get large
file support? I thought in theory it should work out of
the box or at most require adding some suitable define?

        Regards,
                Stefan


**= Email   4 ==========================**

Date:  Mon, 02 May 2005 20:24:01 +0930
From:  Paul Smedley <paul at smedley.info>
Subject:  Re:  Updated Python Build 20050501

Hi Stefan,

Stefan.Neis at t-online.de wrote:
> Paul Smedley schrieb:
> 
>>The major change in this build is that I've made the
>>necessary changes 
>>for large file (ie >2gb) support.
> 
> 
> Any hints on what was actually required to get large
> file support? I thought in theory it should work out of
> the box or at most require adding some suitable define?

I had to specifically add a few #defines to pyconfig.h as we're not yet 
using configure on python for use with Innotek GCC yet.

for EMX we had:
   #define SIZEOF_OFF_T 4

For large file support with Innotek GCC, I needed:
   #define SIZEOF_OFF_T 8
   #define HAVE_LARGEFILE_SUPPORT 1
   #define _FILE_OFFSET_BITS 64
   #define HAVE_FSEEKO 1
   #define HAVE_FTELLO 1

Cheers,

Paul

#endif



**= Email   5 ==========================**

Date:  Mon, 02 May 2005 13:58:06 +0200 (CEST)
From:  Stefan.Neis at t-online.de
Subject:  Re:  Updated Python Build 20050501

         Hi Paul,

Paul Smedley schrieb:

> I had to specifically add a few #defines to pyconfig.h as
> we're not yet 
> using configure on python for use with Innotek GCC yet.

Ah, I see.  It's reassuring to see that that's all... :-)

        Regards,
                Stefan


**= Email   6 ==========================**

Date:  Mon, 02 May 2005 21:30:04 +0930
From:  Paul Smedley <paul at smedley.info>
Subject:   Generating diffs

Hi All,
I've made the necessary changes to a series of files in the Python CVS 
tree to accomodate Innotek gcc, those being:
python\dynload_shlib.c
pc\os2\emx\makefile.inn (new file)
pc\os2\emx\pyconfig.h
modules\socketmodule.c

Is there any easy way to make diffs based on files in two separate trees 
or is it a case of doing diffs on each of the above, then concatenating 
them together?

Cheers,

Paul.


**= Email   7 ==========================**

Date:  Mon, 02 May 2005 14:08:29 +0200 (CEST)
From:  Stefan.Neis at t-online.de
Subject:  Re:  Re:  Request for Comment: Patches for Innotek GCC & Python

Paul Smedley schrieb:

> Once I figure out how to reliably test for Innotek using
> configure :)

In wxWindows, I'm doing the following:

case "${host}" in
  *-pc-os2_emx | *-pc-os2-emx )
      dnl Check for the gcc version (and thereby for the C runtime
library).
      dnl wx_cv_gccversion = EMX2 -> Standard EMX environment
      dnl wx_cv_gccversion = EMX3 -> EMX with gcc-3.0.3 or gcc-3.2.1
      dnl wx_cv_gccversion = Innotek5 -> gcc-3.2.2 with Innotek libc5
      dnl wx_cv_gccversion = Innotek6 -> gcc-3.3.5 with Innotek libc6.
      AC_CACHE_CHECK([for gcc/libc version], wx_cv_gccversion,[
          AC_TRY_RUN(
              dnl Check the gcc version macro.
              [
                  #include <stdio.h>

                  int main()
                  {
                      FILE *f=fopen("conftestval", "w");
                      if (!f) exit(1);
                      fprintf(f,
                  #if (__GNUC__ < 3)
                              "EMX2"
                  #elif (__GNUC__==3) && ((__GNUC_MINOR__ < 2) ||
((__GNUC_MINOR__==2) && (__GNUC_PATCHLEVEL__<2)))
                              "EMX3"
                  #elif (__GNUC__==3) && (__GNUC_MINOR__==2) &&
(__GNUC_PATCHLEVEL__==2)
                              "Innotek5"
                  #else
                              "Innotek6"
                  #endif
                      );
                      exit(0);
                  }
              ],
              wx_cv_gccversion=`cat conftestval`,
              wx_cv_gccversion="EMX2",
              dnl Compilation error: Assuming standard EMX environment
              wx_cv_gccversion="EMX2"
          )
      ])
   ;;

and I'm using the test result like e.g.:

      dnl Explicitly link -lintl if langinfo.h is available
      dnl and intl not yet included in libc
      if test $ac_cv_header_langinfo_h = "yes" \
                -a \(   "$wx_cv_gccversion" = "EMX2" \
                     -o "$wx_cv_gccversion" = "EMX3" \
                     -o "$wx_cv_gccversion" = "Innotek5" \); then
          LIBS="$LIBS -lintl"
      fi

         HTH,
                 Stefan


**= Email   8 ==========================**

Date:  Mon, 02 May 2005 21:59:59 +1100
From:  Andrew MacIntyre <andymac at bullseye.apana.org.au>
Subject:  Re:  Re:  Request for Comment: Patches for Innotek GCC & Python

Paul Smedley wrote:

{...}

>>- 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);
> 
> I'd already suspected this so did a CVS get of the 2.5 source last night
> :)

That will definitely make things easier for getting patches ready for
integration into Python CVS.

To keep your 2.4.x patches handy for the next release on the branch
(probably late this year, unless a critical bug surfaces before then),
you may find it worthwhile to keep a local CVS repo populated with
2.4.x - this is what I did with Python 2.2.x & and it made life a lot
easier for bring out new releases on the branch (2.3 was the first to
have the EMX support from CVS).

>>- 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.
> 
> I don't quite understand this yet but OK :)  I think using ./configure
> is a longer term goal anyway.... configure needs changes at the very
> least to define PYOS_OS2=1 & PYCC_GCC=1/2

In a configure'd build the makefile calls "python setup.py build"
after the python interpreter is built, which then builds the dynamic
extensions.

setup.py uses the Distutils standard library module to actually do the
extension building, after the main part of setup.py has searched for
all the optional bits that could be used for extensions (BSDDB v4,
gdbm etc).

You should be able to get a preliminary check on Distutils support by
trying to build the Numeric extension, which as far as I recall builds
out of the box on the EMX binary.  Numeric has a test suite that can
be used to verify the build.

{...}

>>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
> 
> I can live with this.  This should also work in pyconfig.h as there
> really aren't that many changes, which means it will just be a
> different makefile that is required.

If you're going to defer the configure problem for a bit, then we
can put the detection of the correct PYCC_GCC value directly in
pyconfig.h:

#if defined(__INNOTEK_LIBC__)
#define PYCC_GCC 2
#else
#define PYCC_GCC 1
#endif

(assuming __INNOTEK_LIBC__ is what we should base the decision on)

{...}

> I'll hopefully get some patches to the 2.5 tree to get the Python-cvs to
> the same point with Innotek GCC that I'm at with 2.4.1 - that is -
> problems with curses & bittorrent 4.0 but everything else seems OK.

I went back to the message you sent with the traceback from the curses
module.  I don't think linking is your problem, but I wonder whether
calling conventions might be?  Did you build the curses lib yourself?

The FreeBSD manpages state that nocbreak() changes the tty from raw
mode back to cooked mode - perhaps Thomas Dickey could explain how this
might go wrong.

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).

-------------------------------------------------------------------------
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