osdir.com
mailing list archive

Subject: Re: coreutils-5.0.90 problems on Crays - msg#00058

List: gnu.core-utils.bugs

Date: Prev Next Index Thread: Prev Next Index
Wendy Palm <wendyp@xxxxxxxx> 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.

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.


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


> + #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.


Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

Re: bug in sort

Samuel Irlapati <irlapati@xxxxxxxxxxx> writes: > sort: sort.c:1770: getmonth_mb: Assertion `mblength != (-1) && *wpp == ((void > *)0)' failed. That message isn't generated by GNU sort. Most likely it's a bug in Red Hat's patches to GNU sort, so I'd file a bug report with Red Hat. I would mention the output of the shell commands "sort --version" and "locale" when you file that bug report.

Next Message by Date: click to view message preview

Re: [Bug-gnulib] vasnprintf.m4 patch for Solaris 2.5.1 wcslen problem

Paul Eggert wrote: > > wcslen ../lib/libfetish.a(vasnprintf.o) > > (symbol belongs to implicit dependency /usr/lib/libw.so.1) > > This problem arises because Solaris 2.5.1 puts the following functions > into /usr/lib/libw.so.1, so you need to link with -lw if you use any > of these functions: > > fgetwc fputwc getwc isenglish isideogram isnumber isphonogram isspecial > iswalnum iswalpha iswcntrl iswctype iswdigit iswgraph iswlower iswprint > iswpunct iswspace iswupper iswxdigit mbftowc putwc scrwidth towlower > towupper ungetwc watoll wcscat wcschr wcscmp wcscoll wcscpy wcscspn > wcslen wcsncat wcsncmp wcsncpy wcspbrk wcsrchr wcstod wcstok wcstol > wcstoul wcswcs wcswidth wcsxfrm wctype wcwidth wscasecmp wscat wschr > wscmp wscoll wscpy wscspn wslen wsncasecmp wsncat wsncmp wsncpy wspbrk > wsrchr wstod wstok wstol wstoll wsxfrm Thanks for the analysis. > * m4/vasnprintf.m4 (gl_PREREQ_VASNPRINTF): > Solaris 2.5.1 needs -lw to get the wcslen function. Since vasnprintf.c is also used by libintl (starting from gettext-0.12.2), this would imply making a dependency from libintl.so to libw.so, thus slowing down all internationalized applications... I prefer the appended patch, which I'm committing into gnulib. > I notice that other gnulib modules use the above functions. - In fnmatch.c it is no problem because HANDLE_MULTIBYTE is only defined if mbsrtowcs() is found, which is not the case on Solaris 2.5.1. - In regex.c it is no problem because gnulib doesn't compile regex with MBS_SUPPORT. - In strftime.c it is no problem gnulib doesn't compile strftime with COMPILE_WIDE. Bruno 2003-08-11 Bruno Haible <bruno@xxxxxxxxx> * vasnprintf.c (local_wcslen): New function, for Solaris 2.5.1. (vasnprintf): Use it instead of wcslen. diff -c -3 -r1.4 vasnprintf.c *** vasnprintf.c 15 Jul 2003 12:42:06 -0000 1.4 --- vasnprintf.c 11 Aug 2003 12:57:29 -0000 *************** *** 47,52 **** --- 47,70 ---- # define freea(p) free (p) #endif + #ifdef HAVE_WCHAR_T + # ifdef HAVE_WCSLEN + # define local_wcslen wcslen + # else + /* Solaris 2.5.1 has wcslen() in a separate library libw.so. To avoid + a dependency towards this library, here is a local substitute. */ + static size_t + local_wcslen (const wchar_t *s) + { + const wchar_t *ptr; + + for (ptr = s; *ptr != (wchar_t) 0; ptr++) + ; + return ptr - s; + } + # endif + #endif + char * vasnprintf (char *resultbuf, size_t *lengthp, const char *format, va_list args) { *************** *** 368,374 **** # ifdef HAVE_WCHAR_T if (type == TYPE_WIDE_STRING) tmp_length = ! wcslen (a.arg[dp->arg_index].a.a_wide_string) * MB_CUR_MAX; else # endif --- 386,392 ---- # ifdef HAVE_WCHAR_T if (type == TYPE_WIDE_STRING) tmp_length = ! local_wcslen (a.arg[dp->arg_index].a.a_wide_string) * MB_CUR_MAX; else # endif

Previous Message by Thread: click to view message preview

coreutils-5.0.90 problems on Crays

i've run into a few problems while testing coreutils-5.0.90 and 5.0.1 on the Crays. please consider these small patches: lib/md5.h and src/shred.c need additions to account for the cray's wordsize old crays have the return value int for endusershell and setusershell (incorrect, i know, but nothing's going to get changed at this point in the OS cycle) so src/su.c has a small problem. cray's also have a problem with "[" being in the declaration of a makefile, so src/Makefile.in keeps failing. adding a "\" solves the problem. thanks, wendy -- wendy palm Cray Open Software Development, Cray Inc. wendyp at cray.com, 651-605-9154 # diff -c ./lib/md5.h.orig ./lib/md5.h *** ./lib/md5.h.orig Fri Aug 8 15:11:59 2003 --- ./lib/md5.h Fri Aug 8 15:12:35 2003 *************** *** 63,71 **** # if ULONG_MAX == UINT_MAX_32_BITS typedef unsigned long 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 # endif # endif --- 63,75 ---- # if ULONG_MAX == UINT_MAX_32_BITS typedef unsigned long md5_uint32; # else ! # 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 # endif # endif # endif # # # diff -c ./src/Makefile.in.orig ./src/Makefile.in *** ./src/Makefile.in.orig Fri Aug 8 15:17:33 2003 --- ./src/Makefile.in Fri Aug 8 15:18:04 2003 *************** *** 159,165 **** EXTRA_PROGRAMS = chroot df hostid nice pinky stty su uname uptime users who bin_SCRIPTS = groups ! bin_PROGRAMS = [ chgrp chown chmod cp dd dircolors du \ ginstall link ln dir vdir ls mkdir \ mkfifo mknod mv nohup readlink rm rmdir shred stat sync touch unlink \ cat cksum comm csplit cut expand fmt fold head join md5sum \ --- 159,165 ---- EXTRA_PROGRAMS = chroot df hostid nice pinky stty su uname uptime users who bin_SCRIPTS = groups ! bin_PROGRAMS = \[ chgrp chown chmod cp dd dircolors du \ ginstall link ln dir vdir ls mkdir \ mkfifo mknod mv nohup readlink rm rmdir shred stat sync touch unlink \ cat cksum comm csplit cut expand fmt fold head join md5sum \ *************** *** 296,302 **** EXTRA_PROGRAMS = chroot$(EXEEXT) df$(EXEEXT) hostid$(EXEEXT) \ nice$(EXEEXT) pinky$(EXEEXT) stty$(EXEEXT) su$(EXEEXT) \ uname$(EXEEXT) uptime$(EXEEXT) users$(EXEEXT) who$(EXEEXT) ! bin_PROGRAMS = [$(EXEEXT) chgrp$(EXEEXT) chown$(EXEEXT) chmod$(EXEEXT) \ cp$(EXEEXT) dd$(EXEEXT) dircolors$(EXEEXT) du$(EXEEXT) \ ginstall$(EXEEXT) link$(EXEEXT) ln$(EXEEXT) dir$(EXEEXT) \ vdir$(EXEEXT) ls$(EXEEXT) mkdir$(EXEEXT) mkfifo$(EXEEXT) \ --- 296,302 ---- EXTRA_PROGRAMS = chroot$(EXEEXT) df$(EXEEXT) hostid$(EXEEXT) \ nice$(EXEEXT) pinky$(EXEEXT) stty$(EXEEXT) su$(EXEEXT) \ uname$(EXEEXT) uptime$(EXEEXT) users$(EXEEXT) who$(EXEEXT) ! bin_PROGRAMS = \[$(EXEEXT) chgrp$(EXEEXT) chown$(EXEEXT) chmod$(EXEEXT) \ cp$(EXEEXT) dd$(EXEEXT) dircolors$(EXEEXT) du$(EXEEXT) \ ginstall$(EXEEXT) link$(EXEEXT) ln$(EXEEXT) dir$(EXEEXT) \ vdir$(EXEEXT) ls$(EXEEXT) mkdir$(EXEEXT) mkfifo$(EXEEXT) \ # # # diff -c ./src/shred.c.orig ./src/shred.c *** ./src/shred.c.orig Fri Aug 8 15:36:00 2003 --- ./src/shred.c Fri Aug 8 15:36:32 2003 *************** *** 259,265 **** # if UCHAR_MAX == UINT_MAX_32_BITS typedef unsigned char word32; # else ! "No 32-bit type available!" # endif # endif # endif --- 259,269 ---- # if UCHAR_MAX == UINT_MAX_32_BITS typedef unsigned char word32; # else ! # if UINT_MAX == _UINT_MAX_64 ! typedef unsigned int word32; ! # else ! "No 32-bit type available!" ! # endif # endif # endif # endif # # # diff -c ./src/su.c.orig ./src/su.c *** ./src/su.c.orig Fri Aug 8 15:41:35 2003 --- ./src/su.c Fri Aug 8 15:41:56 2003 *************** *** 144,151 **** --- 144,156 ---- char *crypt (); char *getpass (); char *getusershell (); + #ifdef _UNICOS + int endusershell (); + int setusershell (); + #else void endusershell (); void setusershell (); + #endif /* _UNICOS */ extern char **environ; # # exit # Script finished on Fri Aug 8 15:45:59 2003 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@xxxxxxx http://mail.gnu.org/mailman/listinfo/bug-coreutils

Next Message by Thread: click to view message preview

Re: coreutils-5.0.90 problems on Crays

Paul Eggert wrote: Wendy Palm <wendyp@xxxxxxxx> 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
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by