Building Python 2.2.1 for HP Tru64 UNIX V4.0F

[Phoebe 1]

Narendra,
Did you hack the makefile to add the options? Then it will *not* work.
I think Martin had suggested CC trick, I usually hack the configure.ac to
set the flags since I have lots
of different OS/Archs to support.
Did you do this:
$ make distclean
$ CC="cc -std1 -msg_disable longlongtype"
$ export CC
$ ./configure --with-pydebug
If you did not run configure again (with distclean) it will *not* work.
Anyways I am using DEC/Compaq/HP C compiler V6.2 > . I have it working with
Tru64 Unix 4.0E, 5.0A, 5.1,5.1A (yes, I have all those versions). I don;t
have a 4.0F system,
maybe it is specific to that OS version.  Or it could be your C compiler
version, try to download
the new compiler from the ftp site, there were some issuses with the early
version of 6.0, I have
the 6.2 and 6.3 compilers and I have had no problems.
Cheers

"Narendra Raavi" <narendra at att.com> wrote in message
news:ao2flt$6n39 at kcweb01.netnews.att.com...
>
> All, Thanks for the several suggestions.
>
> 1.a: I am using the --with-pydebug option for configure.
> 1.b: I have the same problem with gcc3.1.
> 1.c: Using "-std1 -msg_disable longlongtype" did not work for Python2.2.1
or
> Python2.2.2b1.
> 1.d: For Python2.2.2b1 the error occurs even earlier:
>
> cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o
> Objects/unicodeobject.
> o Objects/unicodeobject.c
> cc: Error: Objects/unicodeobject.c, line 1235: Invalid expression.
(badexpr)
>         nallocated = Py_SAFE_DOWNCAST(sizeof(stackbuf), size_t, int);
> ---------------------^
> cc: Error: Objects/unicodeobject.c, line 1235: Invalid statement.
(badstmt)
>         nallocated = Py_SAFE_DOWNCAST(sizeof(stackbuf), size_t, int);
> ---------------------^
> cc: Error: Objects/unicodeobject.c, line 1293: Invalid expression.
(badexpr)
>         nneeded = Py_SAFE_DOWNCAST(p - stackbuf, long, int);
> ------------------^
> cc: Error: Objects/unicodeobject.c, line 1293: Invalid statement.
(badstmt)
>         nneeded = Py_SAFE_DOWNCAST(p - stackbuf, long, int);
> ------------------^
> cc: Error: Objects/unicodeobject.c, line 1299: Invalid expression.
(badexpr)
>         nneeded = Py_SAFE_DOWNCAST(p - PyString_AS_STRING(v), long, int);
> ------------------^
> cc: Error: Objects/unicodeobject.c, line 1299: Invalid statement.
(badstmt)
>         nneeded = Py_SAFE_DOWNCAST(p - PyString_AS_STRING(v), long, int);
> ------------------^
> *** Exit 1
> Stop.
>
> 2. The problem seems to be (a) the cpp translation of  this macro OR (b)
the
> __assert implementation (i'm using the example I provided):
>
>  p = (VALUE, WIDE, NARROW) (if ((int) ((WIDE)(NARROW)(VALUE) == (VALUE)))
;
> else __assert("(WIDE)(NARROW)(VALUE) == (VALUE)", "x.c", 17),
> (NARROW)(VALUE))(c, int, char) ;
>
>
> 3. My main motivation in using the --with-pydebug option is to be able to
> dump internals to inspect them. Just learning.
>
> 4. BTW, I love the way the code (that I have looked at - about 35%) is
> written. Clean, easily understood, uncluttered. The Python developers
> deserve kudos for this.
>
> 5. It appears that there is a bug report that has not been fixed. One fix
is
> to replace the assert with a function that actually returns something.
I'll
> try to get this working and see if the Python folks would like a fix.
>
> "Holden Caulfield" <phoebe_1 at att.net> wrote in message
> news:c2595393.0210091225.3a3d4d at posting.google.com...
> > "change" <changeme at changeme> wrote in message
> news:<ao18ke$1tn11 at kcweb01.netnews.att.com>...
> > > Hi,
> > >
> > > I'm trying to build Python 2.2.1 for HP (COMPAQ) Tru64 UNIX V4.0F with
> the
> > > debug option.
> > >
> > > The build fails in Python/marshal.c:
> > >
> > > cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o
> Python/marshal.o
> > > Python/marshal.c
> > > cc: Error: Python/marshal.c, line 64: Invalid expression. (badexpr)
> > >                 *p->ptr++ = Py_SAFE_DOWNCAST(c, int, char);
> > > ----------------------------^
> > > cc: Error: Python/marshal.c, line 64: Invalid statement. (badstmt)
> > >                 *p->ptr++ = Py_SAFE_DOWNCAST(c, int, char);
> > > ----------------------------^
> > > *** Exit 1
> > > Stop.
> > >
> > >
> > > The problem seems to be the definition of Py_SAFE_DOWNCAST in
> > > Include/pyport.h
> > >
> > > #ifdef Py_DEBUG
> > > #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) \
> > >         (assert((WIDE)(NARROW)(VALUE) == (VALUE)), (NARROW)(VALUE))
> > > #else
> > > #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
> > > #endif
> > >
> > >
> > > I also wrote a simple c program mimicking this behavior:
> > >
> > > #include <stdio.h>
> > > #include <assert.h>
> > >
> > >
> > > #define SAFE_DOWNCAST(VALUE, WIDE, NARROW)  (assert
> ((WIDE)(NARROW)(VALUE)
> > > == (VALUE)), (NARROW)(VALUE))
> > >
> > > main () {
> > >
> > >   char p ;
> > >   int c ;
> > >
> > >   c = 65 ;
> > >   p = SAFE_DOWNCAST(c, int, char) ;
> > >
> > >   printf ("INT is: %d  and CHAR is: %c\n", c, p) ;
> > >
> > > }
> > >
> > >
> > > This program does not seem to compile with the cc or the gcc
compilers.
> Is
> > > there a problem with my C compilers or the switches I use with them?
> > >
> > > Thanks,
> > >
> > > Narendra
> >
> >
> > All right do this:
> >
> > CC="cc -std1 -msg_disable longlongtype"
> > export CC
> > ( I am assuming you are bourne/Korn shell)
> > Then run configure again. It will compile fine with or w/o the Debug
> > option
> > enabled.
> > Explanation of the options:
> >  -std1 : This enforces strict compliance with ANSI C standard. Python
> > seems to be one of the few apps that I have had success using the
> > flag. Anyways, it is good thing to be compliant with the standard :) I
> > guess
> >  -msg_disable longlongtype:
> >     All this does is reduce the noise on the long long type being a
> > language extension (it is Informational and *not* warning btw).
> >
> > Now, as to why '-std1' would work. I have not had the time to shift
> > through this. What it does do is define the macro __STDC__ = 1.
> >
> > cheers
>
>