Re: coreutils-5.0.90 problems on Crays

[Wendy Palm]

Paul Eggert wrote:

> Wendy Palm <address@hidden> writes:
>
>
> > ! #    if UINT_MAX == _UINT_MAX_64
> > !       typedef unsigned int md5_uint32;
> > ! #    else
> > !       /* The following line is intended to evoke an error.
> > !          Using #error is not portable enough.  */
> > !       "Cannot determine unsigned 32-bit data type."
> > ! #    endif
>
> Sorry, I don't quite follow the need for this change.  Does that host
> have a working <limits.h>?  If so, <limits.h> should define UINT_MAX,
> USHRT_MAX, and ULONG_MAX.


i do have a limits.h and it does define UINT_MAX, USHRT_MAX
and ULONG_MAX.  but, on a cray, there is no UINT_MAX_32_BITS,
and all these values are set to _UNIT_MAX_64 so the whole ifdef falls through.

> Is the problem that there is no 32-bit integer type on that platform?
> I worry that the code won't work in that case: it really assumes the
> presence of a 32-bit int.
>
> I have the same questions about the similar change to src/shred.c.


traditional cray machines (currently, t3e, sv1, ts, j90) do not have a 32bit 
int.
they have 64 bit ints (all datatypes are 64bits except char and on

the t3e where a short is 32bits).

the newer cray architectures (X1 and on) do have 32bit ints (and the traditional 

long, short, etc. types).

with the change i proposed, the only error i have with the tests is date-tests and 

i haven't had time to check what that problem is yet.

i've run sh-utils with a similar mod for almost 2 years and haven't had any 
problems.

i'd be interested to know what programs are potentially problems with >32bits.
possibly some shifting assumptions may be messed up.


> > ! bin_PROGRAMS = \[ chgrp chown chmod cp dd dircolors du \
>
> Ouch.  I suspect that this will break 'make' programs on other hosts,
> as there's no backslash-escape mechanism like that in standard 'make'.
>
> What exactly is the problem if you use it without the backslash?
> Perhaps there's another way to work around the problem.


i get this error
        cc  -hnointrinsics  -Wl,-Dmsglevel=334:fatal -o [  lbracket.o 
../lib/libfetish.a  ../lib/libfetish.a -lgen
GETTMC: invalid primary machine name on TARGET statement
Make: "cc  -hnointrinsics  -Wl,-Dmsglevel=334:fatal -o [  lbracket.o 
../lib/libfetish.a  ../lib/libfetish.a -lgen ": Error code 1
Make: "make  all-am": Error code 1

doublequotes and singlequotes also work.  would they work on other hosts?


> > + #ifdef _UNICOS
> > + int endusershell ();
> > + int setusershell ();
> > + #else
> >  void endusershell ();
> >  void setusershell ();
> > + #endif /* _UNICOS */
>
> I notice that su.c already does this:
>
> /* Hide any system prototype for getusershell.
>    This is necessary because some Cray systems have a conflicting
>    prototype (returning `int') in <unistd.h>.  */
> #define getusershell _getusershell_sys_proto_
>
> Does a similar trick work for endusershell and setusershell?
> That would be more consistent.


i didn't notice that one.  yes, that would work.




--
wendy palm
Cray Open Software Development, Cray Inc.
wendyp at cray.com, 651-605-9154