[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: coreutils-5.0.90 problems on Crays
From: |
Wendy Palm |
Subject: |
Re: coreutils-5.0.90 problems on Crays |
Date: |
Tue, 12 Aug 2003 16:33:44 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4.1) Gecko/20020406 Netscape6/6.2.2 |
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