|
|
Subject: Re: coreutils-5.0.90 problems on Crays - msg#00058
List: gnu.core-utils.bugs
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?
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
|
|