Re: [bug-gnulib] proposed patch to allocsa, vasnprintf for Tandem NSK (OSS)
Bruno Haible wrote:
Matthew,
The citation in
http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00062.html
looks like it explains why no 'long long' type exists although the machine
would support it. Are you sure the machine supports '[signed] long long'?
Before we engage on a change as large as this, can you please report
the results (output) of the attached program, compiled once with and once
without optimization?
If it doesn't compile, try commenting out one of the lines
#define HAVE_LONGLONG 1
#define HAVE_ULONGLONG 1
As should be expected, I had to take out HAVE_ULONGLONG for it to
compile. I also had to take out several of the comments (non-ASCII
characters were doing Bad Things).
If I am reading this correctly, 'long long' is OK (64-bit), which is a
bit of a relief since one of our products demands an int8(!). The errors
about sign extension were interesting, though.
I'm attaching the non-optimized output. The optimized ('cc -O') output
is identical, plus these two errors:
#error Left shift of integers of type long long does not work!!
#error Right shift of integers of type long long does not work!!
--
Matthew
Will your shell have salvation? Only if it's Bourne Again.
/* Integers of type char have 8 bits. */
#define char_bitsize 8
/* Integers of type short have 16 bits. */
#define short_bitsize 16
/* Integers of type int have 32 bits. */
#define int_bitsize 32
/* Integers of type long have 32 bits. */
#define long_bitsize 32
/* Integers of type long long have 64 bits. */
#define long_long_bitsize 64
/* Integers of type unsigned char have 8 bits. */
/* Integers of type unsigned short have 16 bits. */
/* Integers of type unsigned int have 32 bits. */
/* Integers of type unsigned long have 32 bits. */
/* Integer types char and unsigned char have the same binary representation. */
/* Integer types short and unsigned short have the same binary representation.
*/
/* Integer types int and unsigned int have the same binary representation. */
/* Integer types long and unsigned long have the same binary representation. */
#error Right shift of integers of type char does not work!!
#error Casts from char to short works by zero-extend!!
#error Casts from char to int works by zero-extend!!
#error Casts from char to long works by zero-extend!!
#error Casts from char to long long works by zero-extend!!
#error Casts from char to unsigned short works by zero-extend!!
#error Casts from char to unsigned int works by zero-extend!!
#error Casts from char to unsigned long works by zero-extend!!
/* Pointers of type char * have 32 bits. */
#define pointer_bitsize 32
/* Casts from long * to char * is OK (does nothing). */
/* Casts from char * to long * is OK (does nothing). */
/* Casts from function * to char * is OK (does nothing). */
/* Casts from char * to function * is OK (does nothing). */
/* Type char has sizeof = 1 and alignment = 1. */
#define sizeof_char 1
#define alignment_char 1
/* Type unsigned char has sizeof = 1 and alignment = 1. */
/* Type short has sizeof = 2 and alignment = 2. */
#define sizeof_short 2
#define alignment_short 2
/* Type unsigned short has sizeof = 2 and alignment = 2. */
/* Type int has sizeof = 4 and alignment = 4. */
#define sizeof_int 4
#define alignment_int 4
/* Type unsigned int has sizeof = 4 and alignment = 4. */
/* Type long has sizeof = 4 and alignment = 4. */
#define sizeof_long 4
#define alignment_long 4
/* Type unsigned long has sizeof = 4 and alignment = 4. */
/* Type long long has sizeof = 8 and alignment = 8. */
#define sizeof_long_long 8
#define alignment_long_long 8
/* Type float has sizeof = 4 and alignment = 4. */
#define sizeof_float 4
#define alignment_float 4
/* Type double has sizeof = 8 and alignment = 8. */
#define sizeof_double 8
#define alignment_double 8
/* Type char * has sizeof = 4 and alignment = 4. */
/* Type long * has sizeof = 4 and alignment = 4. */
/* Type function * has sizeof = 4 and alignment = 4. */
/* Type unsigned short is stored BIG-ENDIAN in memory (i.e. like mc68000 or
sparc). */
#define short_big_endian
/* Type unsigned int is stored BIG-ENDIAN in memory (i.e. like mc68000 or
sparc). */
#define int_big_endian
/* Type unsigned long is stored BIG-ENDIAN in memory (i.e. like mc68000 or
sparc). */
#define long_big_endian
/* Stack grows down, ca. 32 bytes per function call. */
#define stack_grows_down
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17908] 'configure' fails because it is unable to determine how to read the mount table.
Jim Meyering wrote: Update of bug #17908 (project coreutils): Severity: 3 - Normal = 2 - Minor ___ Follow-up Comment #3: Thanks for the report. Considering the affected systems are not mainstream, I'm changing severity to minor. Fine with me, since I can't *change* the severity. :-) Thanks... -- Matthew Try to bring it back in one piece this time. -- Q (MI6) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils 6.3 on Tru64 - just plain broken, or...?
Paul Eggert wrote: mwoehlke [EMAIL PROTECTED] writes: source='xstrtoimax.c' object='xstrtoimax.o' libtool=no \ DEPDIR=.deps depmode=tru64 /usr/bin/posix/sh ../build-aux/depcomp \ cc -std -I. -I. -I. -I/home/install/gnu/alpha_osf/include -g -c xstrtoimax.c cc: Warning: ./config.h, line 1741: The redefinition of the macro intmax_t conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. (macroredef) #define intmax_t long long -^ I think I see the problem now; you can't include config.h, then inttypes.h, then config.h, due to config.h having some semi-obsolescent definitions of intmax_t (due to gettext not yet upgrading to assume inttypes.h). I installed this into gnulib to fix things: [patch snipped] Sounds good, thanks! -- Matthew Try to bring it back in one piece this time. -- Q (MI6) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: make check failure on Itanium HPUX
Paul Eggert wrote: mwoehlke [EMAIL PROTECTED] writes: You mean /usr/bin/posix, right? Yes. 14388 Segmentation fault (core dumped) | diff - $t So it looks like 'diff' is broken? I guess so. But that's a different issue. Try removing the broken diff and using the system-standard diff. You can debug diff later. Ok, confirming that diff is broken; 'make check' passed with /usr/bin/diff. Looks like I'll be (hopefully) filing a bug against diffutils. -- Matthew Try to bring it back in one piece this time. -- Q (MI6) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: NSK(OSS) compilation problem
Paul Eggert wrote: mwoehlke [EMAIL PROTECTED] writes: So what would be your recommendation? Remove all use of 64-bit integers? (i.e. make intmax_t also 'long' rather than 'long long'?) No, I'd make uintmax_t 32-bit and intmax_t 64 bit, if those are the widest unsigned and signed types. Then I'd fix any bugs that crop up. Ok... Attaching an initial attempt at a patch for stdint_.h. The configure script (or more appropriately, I suppose, configure.in) needs to be patched additionally, but alas, I do not speak autotools :-), and didn't spot the sources anyway in my brief exploration looking for them. So ignore that part of the patch. And remind me to *NEVER* try to update configure on this box; each run takes an *hour* (yes, this box sucks :-)). Trying to do so basically killed making any headway Friday. At any rate, this is enough to get me started; I will have additional patches as bugs in single programs manifest themselves, but this at least gets things further along. Anyway, this got me as far as sha512.c where the compiler croaked with: ... 0x27b70a8546d22ffcULL, 0x2e1b21385c26c926ULL, 0x4d2c6dfc5ac42aedULL, 0x53380d139d95b3dfULL, 0x650a73548baf63deULL, 0x766a0abb3c77b2a8ULL, 0x81c2c92e47edaee6ULL, 0x92722c851482353bULL, /home/tandem_oss/floss/src/coreutils-6.3/lib/sha512.c, line 399: error(764): invalid unsigned type Error limit reached. 100 errors detected in the compilation of sha512.c. Compilation terminated. (So, yes... yike... Since this thread is already getting old (and likely to get a lot older before I'm done), should I continue this thread even if/when it starts falling off NTP, or start new ones?) What exactly is sha512 used for? It is clear that this code is totally non-portable from the explicit use of 'uint64_t' in sha512.h. (Is this supposed to be excluded from the build, or what? It clearly would not build on any system without a 64-bit integer type...) I also tried the patch on Solaris x86 (manually changing config.h and config.status); there were warnings in fsusage.c, and it failed 'make check' at cp:sparse, dd:skip-seek, du:basic, misc:printf, misc:split-fail, pr:pr-tests (and OMG was that a noisy failure!), tr:tr-tests (not as bad, but still noisy), and uniq:uniq-tests. On an unrelated note, when running configure, I get these two header compilation failures: ... configure: WARNING: sys/statvfs.h: present but cannot be compiled ... configure: WARNING: sys/ioctl.h: present but cannot be compiled ... For now I'm ignoring the ioctl.h one as I don't remember it being a problem. I'll look into the statvfs.h failure when I try to get 'stat' to build (contrary to my previous bug report, statvfs() looks OK so I'm not sure why I couldn't get 'stat' to build on 5.97 - I'm going to try harder this time). My guess, however, is that this is a case of needing _TANDEM_SOURCE defined ala http://savannah.gnu.org/bugs/?17172, but since this would need to be changed in autoconf I'm not sure what, if anything, should or could be done. For statvfs.h: /usr/include/sys/statvfs.h, line 50: error(114): identifier u_long is undefined (I get this on lines 35-43, 45, 46, 48-50) Similarly for ioctl.h it complains about 'u_short', 'u_char', 'caddr_t', etc in /usr/include/net/if_arp.h and /usr/include/net/if.h which are of course inet headers, i.e. this failure exactly matches my description in the bug report. I think there may be some problems with files that double-include config.h. That is a no-no nowadays, since stdint.h redefines uintmax_t and the like. I'll try to look into it. Thanks. (Hmm, that sounds like you got off on a tangent talking about my Tru64 problem?) I think the issues are related. I don't see what including config.h twice has to do with HP NSK/OSS not having an 'unsigned long long' type? But thanks again for fixing that (assuming the patch worked, not sure when I might get around to trying it). -- Matthew What's Cygwin? you ask. 'Tis mostly absurd software Concerning hippos. diff -ur coreutils-6.3-orig/configure coreutils-6.3/configure --- coreutils-6.3-orig/configure2006-09-30 02:09:13.0 -0700 +++ coreutils-6.3/configure 2006-10-09 10:29:25.0 -0700 @@ -715,6 +715,7 @@ LIBICONV LTLIBICONV HAVE_LONG_LONG_INT +HAVE_UNSIGNED_LONG_LONG_INT HAVE_WCHAR_H HAVE_INTTYPES_H HAVE_SYS_TYPES_H @@ -17568,9 +17569,14 @@ cat confdefs.h \_ACEOF #define HAVE_UNSIGNED_LONG_LONG_INT 1 _ACEOF fi + if test $ac_cv_type_unsigned_long_long_int = yes; then +HAVE_UNSIGNED_LONG_LONG_INT=1 + else +HAVE_UNSIGNED_LONG_LONG_INT=0 + fi @@ -62390,6 +62399,7 @@ LIBICONV!$LIBICONV$ac_delim LTLIBICONV!$LTLIBICONV$ac_delim HAVE_LONG_LONG_INT!$HAVE_LONG_LONG_INT$ac_delim +HAVE_UNSIGNED_LONG_LONG_INT!$HAVE_UNSIGNED_LONG_LONG_INT$ac_delim HAVE_WCHAR_H!$HAVE_WCHAR_H$ac_delim HAVE_INTTYPES_H!$HAVE_INTTYPES_H$ac_delim HAVE_SYS_TYPES_H!$HAVE_SYS_TYPES_H$ac_delim @@ -62457,7
Re: NSK(OSS) compilation problem
Paul Eggert wrote: mwoehlke [EMAIL PROTECTED] writes: I have a problem building on Tandem/NSK OSS; specifically, uintmax_t (unsigned long long) is not a valid data type (don't ask me why!). Sorry, but we've gotta ask why. Why isn't it a valid data type? Does the compiler reject 'unsigned long long int x;'? Or does it mishandle code generated with that type? Or what? If you read the bottom of my original post, I already answered that: Unsigned long long: The C++ standard does not specify the long long integer data type; however, it does state that signed integer data types should have an unsigned counterpart. None of the compilers on the TNS/R platform define an unsigned 64-bit data type, and C++ is no exception. *None of the compilers... define an unsigned 64-bit data type...* If you want to know /why/ they don't, you'll have to ask HP. I am thinking about changing this to 'long long', That would break a lot of code. I wouldn't do it. Would it be better to change it to 'unsigned long' instead? uintmax_t should be the widest unsigned integer type that works. If that's 'unsigned long int', then you should use 'unsigned long int'. C does not require that uintmax_t and intmax_t must have the same width. However, I suspect that some gnulib code does assume that uintmax_t is wide enough to represent any nonnegative integer value, which means you may run into trouble if intmax_t, off_t, etc. are wider than uintmax_t. So what would be your recommendation? Remove all use of 64-bit integers? (i.e. make intmax_t also 'long' rather than 'long long'?) And I wonder why I don't remember running into this with 5.97? Also, I don't remember this problem with 5.97 (but I could be wrong); I think there may be some problems with files that double-include config.h. That is a no-no nowadays, since stdint.h redefines uintmax_t and the like. I'll try to look into it. Thanks. (Hmm, that sounds like you got off on a tangent talking about my Tru64 problem?) -- Matthew What's Cygwin? you ask. 'Tis mostly absurd software Concerning hippos. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: NSK(OSS) compilation problem
mwoehlke wrote: I have a problem building on Tandem/NSK OSS; specifically, uintmax_t (unsigned long long) is not a valid data type. [snip] Also, I don't remember this problem with 5.97 (but I could be wrong); [snip] Ah, hmm, maybe '2006-08-21 Jim Meyering [EMAIL PROTECTED]' has something to do with it... -- Matthew What's Cygwin? you ask. 'Tis mostly absurd software Concerning hippos. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
NSK(OSS) compilation problem
I have a problem building on Tandem/NSK OSS; specifically, uintmax_t (unsigned long long) is not a valid data type (don't ask me why!). I am thinking about changing this to 'long long', but before I do that can anyone comment on what potential problems that might cause? Would it be better to change it to 'unsigned long' instead? Also, I don't remember this problem with 5.97 (but I could be wrong); does anyone know if this might have changed recently? I saw '2006-07-02 stdint_.h (intmax_t, uintmax_t)' in ChangeLog but that doesn't sound like it would cause the opposite problem? While trying to find doc for the compiler (it doesn't have a man page), I did find this: Unsigned long long: The C++ standard does not specify the long long integer data type; however, it does state that signed integer data types should have an unsigned counterpart. None of the compilers on the TNS/R platform define an unsigned 64-bit data type, and C++ is no exception. IOW 'unsigned long long' is not supported on Tandem/NSK OSS -- Matthew This message will self destruct in five millennia. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: make check failure on Itanium HPUX
Paul Eggert wrote:
mwoehlke [EMAIL PROTECTED] writes:
Jim Meyering wrote:
mwoehlke [EMAIL PROTECTED] wrote:
mwoehlke wrote:
This is a little odd... 'make' exits non-zero when doing 'make
check' (help-version) on Itanium Linux, but the tests all seem to
pass. Here is the relevant verbose output:
[snip]
...and similarly on HPUX, although the tests pass, 'make check' just
*fails*, and in this case I'm not seeing why. I'm attaching the log in
case anyone spots something I didn't. (Maybe it's the same problem?)
This bit looks like the cause:
t=ls-files.$$; \
(cd . ls -1 *.x) | sed 's/\.x$//' | LC_ALL=C sort $t;\
echo base64.1 basename.1 cat.1 chgrp.1 chmod.1 chown.1 chroot.1 cksum.1
comm.1 cp.1 csplit.1 cut.1 date.1 dd.1 df.1 dir.1 dircolors.1 dirname.1 du.1
echo.1 env.1 expand.1 expr.1 factor.1 false.1 fmt.1 fold.1 groups.1 head.1
hostid.1 hostname.1 id.1 install.1 join.1 kill.1 link.1 ln.1 logname.1 ls.1
md5sum.1 mkdir.1 mkfifo.1 mknod.1 mv.1 nice.1 nl.1 nohup.1 od.1 paste.1
pathchk.1 pinky.1 pr.1 printenv.1 printf.1 ptx.1 pwd.1 readlink.1 rm.1 rmdir.1
seq.1 sha1sum.1 sha224sum.1 sha256sum.1 sha384sum.1 sha512sum.1 shred.1 shuf.1
sleep.1 sort.1 split.1 stat.1 stty.1 su.1 sum.1 sync.1 tac.1 tail.1 tee.1
test.1 touch.1 tr.1 true.1 tsort.1 tty.1 uname.1 unexpand.1 uniq.1 unlink.1
uptime.1 users.1 vdir.1 wc.1 who.1 whoami.1 yes.1 | tr -s ' ' '\n' | sed
's/\.1$//' \
| LC_ALL=C sort | diff - $t || { rm $t; exit 1; };\
rm $t
/usr/bin/posix/sh[5]: 12357 Memory fault(coredump)
make[2]: *** [check-x-vs-1] Error 1
Yup, it does; didn't spot that. But...
(do you have /usr/bin/posix in your shell's search path?)
...no I don't.
I'd guess it's pulled in because 'configure' tries /usr/posix/bin/sh.
You mean /usr/bin/posix, right?
Anyway, to me that looks like a fluke
since 'make check' shouldn't be doing anything in 'man', yes?
'make check' does the equivalent of 'make', so it does things
in 'man'. And so it's not a fluke; it's a real problem of
some sort with your /usr/posix/bin/sh implementation.
Ok, but actually this is something that 'make check' does that 'make'
doesn't (looks like it verifies that all manpages are there?); 'make' in
just man/ reports 'nothing to do', whereas 'make check' produces this error.
Can you reproduce the problem by hand? For example, does the
following shell script dump core for you, when you execute it in your
man directory?
#! /bin/sh
/usr/posix/bin/sh -c 'PATH=../src:$PATH; export PATH; \
t=ls-files.$$; \
(cd . ls -1 *.x) | sed '\''s/\.x$//'\'' | LC_ALL=C sort $t;\
echo base64.1 basename.1 cat.1 chgrp.1 chmod.1 chown.1 chroot.1 cksum.1
comm.1 cp.1 csplit.1 cut.1 date.1 dd.1 df.1 dir.1 dircolors.1 dirname.1 du.1
echo.1 env.1 expand.1 expr.1 factor.1 false.1 fmt.1 fold.1 groups.1 head.1
hostid.1 hostname.1 id.1 install.1 join.1 kill.1 link.1 ln.1 logname.1 ls.1
md5sum.1 mkdir.1 mkfifo.1 mknod.1 mv.1 nice.1 nl.1 nohup.1 od.1 paste.1
pathchk.1 pinky.1 pr.1 printenv.1 printf.1 ptx.1 pwd.1 readlink.1 rm.1 rmdir.1
seq.1 sha1sum.1 sha224sum.1 sha256sum.1 sha384sum.1 sha512sum.1 shred.1 shuf.1
sleep.1 sort.1 split.1 stat.1 stty.1 su.1 sum.1 sync.1 tac.1 tail.1 tee.1
test.1 touch.1 tr.1 true.1 tsort.1 tty.1 uname.1 unexpand.1 uniq.1 unlink.1
uptime.1 users.1 vdir.1 wc.1 who.1 whoami.1 yes.1 | tr -s '\'' '\'' '\''\n'\''
| sed '\''s/\.1$//'\'' \
| LC_ALL=C sort | diff - $t || { rm $t; exit 1; };\
rm $t'
Hmm... actually it does (you meant '/usr/bin/posix/sh', not
'/usr/posix/bin/sh')... Also, if I re-run with bash, I get:
bash: line 5: 14384 Doneecho base64.1 basename.1
cat.1 chgrp.1 chmod.1 chown.1 chroot.1 cksum.1 comm.1 cp.1 csplit.1
cut.1 date.1 dd.1 df.1 dir.1 dircolors.1 dirname.1 du.1 echo.1 env.1
expand.1 expr.1 factor.1 false.1 fmt.1 fold.1 groups.1 head.1 hostid.1
hostname.1 id.1 install.1 join.1 kill.1 link.1 ln.1 logname.1 ls.1
md5sum.1 mkdir.1 mkfifo.1 mknod.1 mv.1 nice.1 nl.1 nohup.1 od.1 paste.1
pathchk.1 pinky.1 pr.1 printenv.1 printf.1 ptx.1 pwd.1 readlink.1 rm.1
rmdir.1 seq.1 sha1sum.1 sha224sum.1 sha256sum.1 sha384sum.1 sha512sum.1
shred.1 shuf.1 sleep.1 sort.1 split.1 stat.1 stty.1 su.1 sum.1 sync.1
tac.1 tail.1 tee.1 test.1 touch.1 tr.1 true.1 tsort.1 tty.1 uname.1
unexpand.1 uniq.1 unlink.1 uptime.1 users.1 vdir.1 wc.1 who.1 whoami.1 yes.1
14385 | tr -s ' ' '\n'
14386 | sed 's/\.1$//'
14387 | LC_ALL=C sort
14388 Segmentation fault (core dumped) | diff - $t
So it looks like 'diff' is broken?
$ diff --version
diff (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
Re: make check failure on Itanium HPUX
Jim Meyering wrote:
mwoehlke [EMAIL PROTECTED] wrote:
mwoehlke wrote:
This is a little odd... 'make' exits non-zero when doing 'make
check' (help-version) on Itanium Linux, but the tests all seem to
pass. Here is the relevant verbose output:
[snip]
...and similarly on HPUX, although the tests pass, 'make check' just
*fails*, and in this case I'm not seeing why. I'm attaching the log in
case anyone spots something I didn't. (Maybe it's the same problem?)
This bit looks like the cause:
t=ls-files.$$; \
(cd . ls -1 *.x) | sed 's/\.x$//' | LC_ALL=C sort $t;\
echo base64.1 basename.1 cat.1 chgrp.1 chmod.1 chown.1 chroot.1 cksum.1
comm.1 cp.1 csplit.1 cut.1 date.1 dd.1 df.1 dir.1 dircolors.1 dirname.1 du.1
echo.1 env.1 expand.1 expr.1 factor.1 false.1 fmt.1 fold.1 groups.1 head.1
hostid.1 hostname.1 id.1 install.1 join.1 kill.1 link.1 ln.1 logname.1 ls.1
md5sum.1 mkdir.1 mkfifo.1 mknod.1 mv.1 nice.1 nl.1 nohup.1 od.1 paste.1
pathchk.1 pinky.1 pr.1 printenv.1 printf.1 ptx.1 pwd.1 readlink.1 rm.1 rmdir.1
seq.1 sha1sum.1 sha224sum.1 sha256sum.1 sha384sum.1 sha512sum.1 shred.1 shuf.1
sleep.1 sort.1 split.1 stat.1 stty.1 su.1 sum.1 sync.1 tac.1 tail.1 tee.1
test.1 touch.1 tr.1 true.1 tsort.1 tty.1 uname.1 unexpand.1 uniq.1 unlink.1
uptime.1 users.1 vdir.1 wc.1 who.1 whoami.1 yes.1 | tr -s ' ' '\n' | sed
's/\.1$//' \
| LC_ALL=C sort | diff - $t || { rm $t; exit 1; };\
rm $t
/usr/bin/posix/sh[5]: 12357 Memory fault(coredump)
make[2]: *** [check-x-vs-1] Error 1
Yup, it does; didn't spot that. But...
(do you have /usr/bin/posix in your shell's search path?)
...no I don't.
$ which -a sh
/usr/bin/sh
$ ll /usr/bin/sh
-r-xr-xr-x 2 bin bin 544232 Aug 8 2002 /usr/bin/sh
So unless this is some weird HPUX thing I'm not sure where
/usr/bin/posix/sh came from. Anyway, to me that looks like a fluke since
'make check' shouldn't be doing anything in 'man', yes? IOW this one can
be safely ignored?
--
Matthew
I don't question your existence -- God (seen on a church billboard)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils 6.3 on Tru64 - just plain broken, or...?
...is anyone else trying to build on Tru64? I'm using 4.0G to build, and I have a LOT of problems. For starters, things went badly until I removed the #define for intmax_t from config.h. shuf builds, but the linker complains about 'ftello unresolved', and then *produces a file* (but without +x), with the result that 'make' then thinks it has nothing to do to for target 'shuf' and continues on to success if re-run. 'make check' bombed because it failed to find perl (despite it being in my path the whole time), although it looks like my perl may be broken (didn't find strict.pm after I forcibly pointed the Makefile's at it). Building perl is not going to happen; after an hour trying to get the POS Configure to run I gave up and deleted it with extreme prejudice. Instead I ran the 'make check' on a 5.1 box, and then got memory faults all over the place (log attached; I also have the full verbose run, but it's ~45kb bzip2'd). So... has anyone else tried Tru64? -- Matthew I don't question your existence -- God (seen on a church billboard) *** NOTICE: Some tests may be run only as root. Do `make check-root' as `root' to run these tests. *** Making check in chgrp make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chgrp' make check-TESTS make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chgrp' ./no-x: this test requires that you be a member of more than one group, but running `id -G' either failed or found just one. If you really are a member of at least two groups, then rerun this test with COREUTILS_GROUPS set in your environment to the space-separated list of group names or numbers. E.g., env COREUTILS_GROUPS='users cdrom' make check SKIP: no-x ./posix-H: this test requires that you be a member of more than one group, but running `id -G' either failed or found just one. If you really are a member of at least two groups, then rerun this test with COREUTILS_GROUPS set in your environment to the space-separated list of group names or numbers. E.g., env COREUTILS_GROUPS='users cdrom' make check SKIP: posix-H ./basic: this test requires that you be a member of more than one group, but running `id -G' either failed or found just one. If you really are a member of at least two groups, then rerun this test with COREUTILS_GROUPS set in your environment to the space-separated list of group names or numbers. E.g., env COREUTILS_GROUPS='users cdrom' make check SKIP: basic ./deref: this test requires that you be a member of more than one group, but running `id -G' either failed or found just one. If you really are a member of at least two groups, then rerun this test with COREUTILS_GROUPS set in your environment to the space-separated list of group names or numbers. E.g., env COREUTILS_GROUPS='users cdrom' make check SKIP: deref ./recurse: this test requires that you be a member of more than one group, but running `id -G' either failed or found just one. If you really are a member of at least two groups, then rerun this test with COREUTILS_GROUPS set in your environment to the space-separated list of group names or numbers. E.g., env COREUTILS_GROUPS='users cdrom' make check SKIP: recurse == All 0 tests passed (5 tests were not run) == make[2]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chgrp' make[1]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chgrp' Making check in chmod make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chmod' make check-TESTS make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chmod' PASS: inaccessible PASS: c-option PASS: equal-x PASS: equals PASS: no-x PASS: octal PASS: setgid PASS: umask-x PASS: usage == All 9 tests passed == make[2]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chmod' make[1]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chmod' Making check in chown make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chown' make check-TESTS make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chown' *** NOTICE: ./basic: This test is being skipped, since it works only when run as root. *** SKIP: basic PASS: deref PASS: separator == All 2 tests passed (1 tests were not run) == make[2]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chown' make[1]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chown' Making check in cp make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/cp' make check-TESTS make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/cp' PASS: src-base-dot ./sparse: 343414 Memory fault ./sparse: 343422 Memory fault
Re: make check failure on Itanium Linux
mwoehlke wrote: This is a little odd... 'make' exits non-zero when doing 'make check' (help-version) on Itanium Linux, but the tests all seem to pass. Ack, nope, scratch that, there were real failures in there too... grep found them (my eyes did not :-(). ia64_linux:FAIL: dir2dir ia64_linux:FAIL: no-target-dir Will try to take a look later... -- Matthew I don't question your existence -- God (seen on a church billboard) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Darwin - GOOD news
The 'rm' problem is gone on Darwin (x86 and PowerPC; didn't remember it affecting x86 but it popped up once as I was building 6.3, when 'rm' was still picking up the one from 5.97). Thanks for the patches! Still the same 'make check' failures, but only on NFS; at least one of which was determined to be a buggy kernel/NFS driver. Not sure if I'll get to ktrace'ing the others or not. Other than the above, NSK(OSS) which I am still working on, and the aforementioned fubar'd Tru64, my only failures (on 12 platforms) are: ia64_linux:FAIL: dir2dir ia64_linux:FAIL: no-target-dir iris_irix:FAIL: date -- Matthew I don't question your existence -- God (seen on a church billboard) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: OT: latest stable version not recommended
[EMAIL PROTECTED] wrote: On 2006-09-27 19:00:44 -0500, mwoehlke [EMAIL PROTECTED] said: Paul Eggert wrote: [EMAIL PROTECTED] writes: Can I validly talk Apple into upgrading their provided gzip to 1.3.5 when this is not in the stable category (for _whatever_ reason[s])? If 1.3.5 is fine to use, it needs to be assigned as such, or Apple would find an argument to close the bug rather quickly. Debian stable uses gzip 1.3.5. Solaris 10 uses gzip 1.3.3. (Both have added patches, for security reasons.) Anybody using gzip 1.2.4 in this day and age ought to have their head examined. Ok, as one of anybody, I have to object to that... The problem is the only thing advertised *anywhere* is 1.2.4. I had to look *really closely* at http://www.gzip.org to find 1.3.3 (and don't even bother with http://directory.fsf.org/gzip.html; no mention there)... which, of course, is labeled beta and doesn't mention anything about 1.2.4 being bad. And darned if I found a 1.3.5 anywhere except http://gnuwin32.sourceforge.net. If I have to be an insider to have any clue that 1.2.4 is bad, then someone (multiple someone's, really) is SERIOUSLY dropping the ball as a maintainer. Yes if one doesn't know about the alpha FTP site, one wouldn't find the official gzip-1.3.5 sourceball: ftp://alpha.gnu.org/gnu/gzip Right, but of course I didn't find any *links* to that. IOW, as you said, one has to just know that it exists. And further that despite its alpha status, people really do recommend using it. Now look at the dates -- this has been tucked away for four years?!?!?? (fwiw apparently gzip is so old, there are no discussions groups, mail-lists, or web forums for it; gmane only carries info-zip and 7zip groups here... so how would one get word out?) Old, and apparently unmaintained, which was sort of my original point. Word would get out by a new stable release (as we've said, isn't it about time?!), which would be announced on, at minimum, http://www.gzip.org and http://directory.fsf.org/gzip.html. -- Matthew Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: OT: latest stable version not recommended
Karl Berry wrote: with http://directory.fsf.org/gzip.html; no mention there)... which, of 1.3.5 is mentioned on that Directory page as the (devel) release. Anyway, I wrote rms about the lack of official releases in recent decades. Ah, my bad... but then, it's still just devel (which means 'not stable - DON'T USE!' to a maintainer of production systems), none of the no, really, you DON'T want to use 1.2.4 stuff I've been hearing. At any rate, there still isn't a download link for it, so one still has to go hunting for where to get it (and if someone who hasn't heard of alpha.gnu.org comes along, they won't know where to get it). Excuse me while I e-mail JLG. 7 years is about long enough for a new release I think. (Anyone here want to hear how it goes?) -- Matthew Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Darwin - chmod broken?
Paul Eggert wrote: mwoehlke [EMAIL PROTECTED] writes: 10487 chmodCALL chmod(0x2800600,0x1a4) 10487 chmodNAMI . 10487 chmodRET chmod 0 10487 chmodCALL chmod(0x2800600,0x1a4) 10487 chmodNAMI b 10487 chmodRET chmod 0 10487 chmodCALL close(0x1) 10487 chmodRET close 0 10487 chmodCALL exit(0) Does that look right? No. It looks like your kernel is busted. The first chmod sets the permissions of . to 644, i.e., nobody can search it. But the second chmod searches . successfully. Yup, that's what I'm seeing. Are you running this test as root? Nope. If I am reading 'man 2 chmod' right, the second chmod() is expected to fail with EACCES? Yes, that's right. It looks like your operating system is buggy. Wow... you ain't kidding... $ ll -d . b drwxr-xr-x 3 install sstest 512 Sep 27 08:26 . drwxr-xr-x 2 install sstest 512 Sep 26 15:20 b $ /bin/chmod a-x . b $ ll -d . b drw-r--r-- 3 install sstest 512 Sep 27 08:26 . drw-r--r-- 2 install sstest 512 Sep 26 15:20 b $ ll -d . b drw-r--r-- 3 install sstest 512 Sep 27 08:26 . drw-r--r-- 2 install sstest 512 Sep 26 15:20 b $ chmod a+x . chmod: changing permissions of `.': Permission denied $ chmod a+x b chmod: cannot access `b': Permission denied $ /bin/chmod a+x . chmod: .: Permission denied $ ll -d . b ls: .: Permission denied ls: b: Permission denied $ WTF just happened there?! :-) Apparently the permissions are being cached and not flushed immediately as far as access control, but are being returned accurately for 'ls'... that's pretty messed up. So I guess this failure is a red herring at least as far as anything being wrong with coreutils. Wow, that's a broken OS/kernel/driver/one-of-the-above... (Might be the NFS driver, since this didn't break when run on a local mount.) Can you reproduce this bug with /bin/chmod? Yup (See above). I'll investigate the other failures, but if I can demonstrate that a: the OS is broken, and b: the OS's version of the same utility is similarly broken, I'll just leave my reports at that (unless someone objects to this plan). Anyway, thanks for all the help! -- Matthew The hippo made me do it! What? What do you mean you can't see the hippo? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
What to do with 'make check'?
I am shortly going to try running 'make check' on about 10-12 platforms, but I have a few questions... 1. I should be able to get root access to all the build machines, but they are not my machines... how safe is running 'make check' as root? 2. I am expecting a number of failures. How should I report these? Post the entire 'make check' output, just the names of the failed tests, or something in-between? Is there other information (besides the build platform, obviously!) I should provide? I.e. to what extent will I have to chase down bugs myself (or should I post results first, and go from there)? 3. How important are the local-file-system tests? Running them will be more complicated if I have to find local drive space to build and run the tests (and will hurt my ability to automate the process). -- Matthew Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: What to do with 'make check'?
(Replying here, since this is now a reply to something like 3-4 posts) Hey! I just noticed, the rm test ONLY fails on NFS. I will try the CONSECUTIVE_READDIR thing shortly. Meanwhile, here's everything that broke. There are now two master logs, -nfs and -local for what FS each one ran on. For each test that failed there is also a VERBOSE-yes log for that test (chgrp-basic was run on local, the rest on NFS). Paul Eggert wrote: mwoehlke [EMAIL PROTECTED] writes: Will do. Is it OK to bzip2 the results? Remember I expect to have several (as many as 10) of these! It's OK to bzip2 them. If things get too long you can simply give us a URL. Hopefully they won't get that big (especially as I have no web space to post them to). I am attaching make check (8 failures) for: $ uname -srvmpio Darwin 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc RackMac3,1 Darwin I'll watch to see if the attachment gets stripped... -- Matthew Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat. coreutils-6.3-check-power_darwin.tar.bz2 Description: BZip2 compressed data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)
Jim Meyering wrote: mwoehlke [EMAIL PROTECTED] wrote: # using THRESHOLD = 150 $ tar xzf coreutils-6.3.tar.gz $ until /path-to-rm -rf coreutils-6.3 ; do : ; done # using THRESHOLD = 200 (default) $ tar xzf coreutils-6.3.tar.gz $ until /path-to-rm -rf coreutils-6.3 ; do : ; done /path-to-rm: cannot remove directory `coreutils-6.3/m4': Directory not empty /path-to-rm: cannot remove directory `coreutils-6.3/lib': Directory not empty ...so that is definitely the problem. Trying a few more values, I see: 150 - works 200 - broken 175 - works 190 - broken (but only in m4, not lib) 185 - works 188 - broken (same as 190) 187 - works Honestly, I would probably go with 160-ish to be safe. :-) Thanks. I'll use 180. The lower we go, the more of a performance penalty we impose for directories with very many entries. Already, in implementing remove.c that way, I've compromised (however slightly) how GNU rm works in general, for the sake of working reliably even on such broken file systems. Have you considered making this conditional to broken Darwin versions? :-) Anyway, just caught the check-in too, thanks. -- Matthew Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Dawrin- why does pinky SIGBUS (was: What to do with 'make check'?)
Paul Eggert wrote: [for power_darwin-local] Why does pinky dump core? What does ktrace say for it? Well, for starters... (gdb) run Starting program: /home/install/gnu/power_darwin/bin/pinky Reading symbols for shared libraries +.. done Reading symbols for shared libraries . done [snip many repetitions of the above] Reading symbols for shared libraries . done LoginName TTY Idle When Where Program received signal EXC_BAD_ACCESS, Could not access memory. 0x90007260 in strlen () (gdb) bt #0 0x90007260 in strlen () #1 0x9000d1d8 in strdup () #2 0x393c in canon_host_r (host=0xfffc Address 0xfffc out of bounds, cherror=0x8248) at canon-host.c:74 #3 0x2df8 in print_entry (utmp_ent=0x0) at pinky.c:305 #4 0x342c in scan_entries (n=1, utmp_buf=0x18013d4, argc_names=0, argv_names=0xbb20) at pinky.c:476 #5 0x34c4 in short_pinky (filename=0x796c /var/run/utmp, argc_names=25170900, argv_names=0xbb20) at pinky.c:494 #6 0x38a4 in main (argc=1, argv=0xbb1c) at pinky.c:622 (gdb) Honestly I have never used pinky so I don't really care. (WAG: print_entry is missing a check for NULL?) I'll take a look at some of the others with ktrace (hmm, why does the test that wants strace not know about ktrace?). -- Matthew Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Darwin - chmod broken? (was: What to do with 'make check'?)
Paul Eggert wrote: [for chmod/no-x] + mkdir -p a/b + cd a + chmod a-x . b + fail=1 This indicates that chmod a-x . b succeeded, but it should have failed because it should have made . unsearchable before attempting to access b (aka ./b). Again, can you please try to see what system calls chmod is doing, with ktrace -o /tmp/tr chmod a-x . b? You are looking for this, yes? 10487 chmodCALL chmod(0x2800600,0x1a4) 10487 chmodNAMI . 10487 chmodRET chmod 0 10487 chmodCALL chmod(0x2800600,0x1a4) 10487 chmodNAMI b 10487 chmodRET chmod 0 10487 chmodCALL close(0x1) 10487 chmodRET close 0 10487 chmodCALL exit(0) Does that look right? Is chmod (the program) supposed to re-evaluate its permissions before calling chmod() the second time (if so, that's not happening), or is the second chmod() supposed to fail (which would mean the OS is buggy)? If I am reading 'man 2 chmod' right, the second chmod() is expected to fail with EACCES? -- Matthew Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)
[EMAIL PROTECTED] wrote: [let me see if gmane lets me reply to posts] gmane works great, it's the only way I read this list (and several others). :-) btw, thanks for the mails... I just built coreutils on Darwin also, and had a good number of 'make check' failures. I am also noticing that after making coreutils (and some other packages, I think bash was one), to remove the directory, I have to 'rm -rf coreutils-5.97' as many as four times before it fully goes away. Odd that just doing it several times in succession works, though. -- Matthew KDE: Desktop Excellence ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [patch] Get coreutils 6.1 to build on a ANSI 89 compiler
Bob Proulx wrote: mwoehlke wrote: Right. Most likely I will build the next stable coreutils across the board, at which point I expect I will probably file a few bug reports (or one, with many parts) detailing how to detect and enable c99 for various platforms (particularly on systems where the answer is an esoteric compiler option rather than 'c99'). Hmm... You have stated what is often a common circular dependency. When the code becomes perfect and won't change anymore then try it on all of the peripheral platforms. But those platforms are bound to expose issues that we won't know about until you try it there. A circular dependency. I am guilty of that myself at times. But it would be better for the project if you could try it while it is developing and then report problems before it is declared to be perfect. Then the stable release really will work on that platform. Sigh. Should've seen this coming. The problem is that I am maintaining a toolset for use by several people that (to be honest) may or may not realize they're using a custom toolset. For this reason, I am not going to put into production anything the developers do not believe is stable (most of the problems I run into are minor build errors, not show-stoppers; i.e. not things that affect my confidence that the program will behave as expected and intended). Plus it takes a good deal of time to build that many platforms, and I am doing this on the side. But I guess you've talked me into it, if I get time. What I am NOT going to do is install an unstable toolset. What I am willing to do is 'make' and 'make test'. (Or is it 'make check? I always forget :-).) Then I can bring up any test failures. Checking the two most likely suspects, however; I don't see a 'c99' on NSK/OSS, and the help for 'cc' mentions 'c89', which is not a good sign. Irix however has a 'c99', and I *think* the rest of my set probably have some means of compiling c99. As Paul noted gcc 3.x is enough and in the cases that I know about the commercial vendor native C compilers also support declarations after statements. On HP-UX I build with the native C compiler and it supports it. On some platforms you may want to update gcc. On others you may have to use the patch. I think OSS/NSK would need the patch. I'm not sure how inclined I am to try to build gcc on that platform... or even a new coreutils for that matter; building 5.97 was painful enough :-). -- Matthew 73% of all statistics are made up on the spot. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [patch] Get coreutils 6.1 to build on a ANSI 89 compiler
Bob Proulx wrote: Petter Reinholdtsen wrote: The ANSI C 89 compilers refuses code that fail to declare variables at the start of the block. I found this problem on RHEL 2.1. The code refused to compile, and I have to move the variables up to the start of the block to get it building. One of the reasons for the soft requirement of C99, I say soft because Jim included an easy way to patch the code back to C89, was because is it believed that non-C99 capable systems are now so old as to be either obsolete or hobby only systems. Having a default compilation fail on those system is one way of discovering any real system that actually is still alive out of hiding. With that in mind may I ask a few questions? (Please make sure to keep the mailng list address in the reply.) * What architecture are you using RHEL 2.1 AS on? uname -m * What compiler is available on that platform? gcc --version * What libc is available there? ldd --version And now the big question. Could you say a few words about why you are using that platform? RHEL 2.1 AS released in May 2002. That is four years old now. There are certainly good reasons to keep using a stable platform. But you are trying to compile a new coreutils there which implies that you are not keeping that platform stable and are instead trying to pull it forward. Wouldn't it be better in that case to upgrade to a more recent system? Ok, I've been wanting to say something for a while, and you just gave me an opening. I have built coreutils (actually, a nice GNU suite plus a few others like VIM7) on over a half dozen platforms, including Solaris 2.7, Irix, HPUX 11.x, AIX... and of course Linux. These are old systems, but they are still used in production (we keep them because our customers still use them). I keep noticing that people seem to want to only support GNU software on the latest stable release of Linux, and that really bothers me. The great thing about GNU is that is isn't limited to just Linux, and I think continuing to support platforms that are still used in production environments is important. Now, to answer the original question, I *think* most of those have a C99 compiler available, but without checking all ten OS/hardware combinations (not counting Cygwin, where I use the officially maintained toolchain), I can't say that with certainty. I'm not against making C99 a *soft* requirement (part of building that toolchain I mentioned was dealing with non-C99 compilers - not just with coreutils), especially if configure tries to find a C99 compiler if you didn't point it at one explicitly (how many OS's does this work with, btw?), but there are still systems used by real people (and by big companies!) that certainly don't have C99 by default. -- Matthew KATE: Awesome Text Editor ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [patch] Get coreutils 6.1 to build on a ANSI 89 compiler
Bob Proulx wrote: mwoehlke wrote: I have built coreutils (actually, a nice GNU suite plus a few others like VIM7) on over a half dozen platforms, including Solaris 2.7, Irix, HPUX 11.x, AIX... and of course Linux. These are old systems, but they are still used in production (we keep them because our customers still use them). Hmm... Are your customers also using the latest code on those machines? I would guess those are effectively stable appliances which is why they are frozen there. Running with the latest code is not going to match their environment. And if the customers were using the latest software then I would pose the same question to them concerning modifying it with upgrades. Some have issues upgrading, yes, but many of them do upgrade. Some of them are also government, or otherwise have strange rules or problems regarding ability to upgrade (either hardware, software, or both). (Since I'm essentially hijacking your request for comments, I'll take my other comments to Paul's much more succinct reply, and reply only to direct questions or things relevant to your original question.) Now, to answer the original question, I *think* most of those have a C99 compiler available, but without checking all ten OS/hardware combinations (not counting Cygwin, where I use the officially maintained toolchain), I can't say that with certainty. How would you propose that we determine this information? I can't think of a better way than to make a coreutils release that relies upon the desired c99 features, with an easy way to patch back to c89. If there are no bug reports of any type then we can assume that no one is using new coreutils on museum pieces. If there are lots of real and valid bug reports then we have our information. Right. Most likely I will build the next stable coreutils across the board, at which point I expect I will probably file a few bug reports (or one, with many parts) detailing how to detect and enable c99 for various platforms (particularly on systems where the answer is an esoteric compiler option rather than 'c99'). I think this is okay because by definition if you are compiling source code you have assumed the role of a developer, or at least a code porter, and developers and code porters are assumed to have a higher skill level than a non-developer. This issue is well within reason to expect them to be able to deal with effectively. With the README saying explicitly what needs to be done and the patch provided it is very easy. Perhaps too easy. Right. We are in violent agreement. :-) I'm not against making C99 a *soft* requirement (part of building that toolchain I mentioned was dealing with non-C99 compilers - not just with coreutils), especially if configure tries to find a C99 compiler if you didn't point it at one explicitly (how many OS's does this work with, btw?), but there are still systems used by real people (and by big companies!) that certainly don't have C99 by default. So let's turn this into useful information. Among the platforms that you are using do you have any that are not capable of using a c99 compiler? Again, without checking I won't know, but I think you've got the right strategy here. As mentioned above, once there is a stable release out (sounds like it will be relatively soon), I expect to do a round of builds, at which point I'll be able to tell you what broke and (hopefully) how to fix it. Checking the two most likely suspects, however; I don't see a 'c99' on NSK/OSS, and the help for 'cc' mentions 'c89', which is not a good sign. Irix however has a 'c99', and I *think* the rest of my set probably have some means of compiling c99. I am not sure coreutils would be doing a service to the community to add automatic back patching of the code on systems without c99 available. Having to do it explicitly today acts as a wakeup-call to people that they should be thinking and planning for how to deal with the support issue for their ancient platform. Nope, no disagreements here. :-) -- Matthew KATE: Awesome Text Editor ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [patch] Get coreutils 6.1 to build on a ANSI 89 compiler
Paul Eggert wrote: mwoehlke [EMAIL PROTECTED] writes: people seem to want to only support GNU software on the latest stable release of Linux That may be true for other packages but it's not true of coreutils. Coreutils is built fairly regularly on older systems, even systems like Solaris 2.6 (released 1997) that are no longer supported by their original suppliers. I know, it just seems like a number of the conversations here about potentially-high-impact changes have been carried on as if Linux 2.6 was the only supported platform. For instance, the recent conversation about openat, etc, mentioned corner cases that might cause a Linux system to not have /proc. What I don't recall seeing is ANY concern for systems that don't even *have* /proc. Now I know that in this case we're talking about something where the emulation layer is reported to work well, but again, it's the *appearance* of not caring about other platforms that worries me. Since I don't have the ability to read the official developer's thoughts, I have to rely on what I see here, and when all I see is concern about Linux without concern for other platforms where I would expect to see some (even if only, oh, yeah, and the emu layer will handle other OS's), I get a little worried. :-) At any rate, thank you both (Paul and Bob) for the reassurance that non-Linux is not forgotten. :-) -- Matthew KATE: Awesome Text Editor ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Coretutils tail command no longer correctly accepting +2 as a parameter
Eric Blake wrote: According to Bruce Baxter on 9/14/2006 10:42 PM: The GNU coreutils version 5.97 (included with Fedora Core 5 in RPM coreutils-5.97-1.2) returns an error, for example: tail: cannot open `+2' for reading: No such file or directory This is not a bug in coreutils, but a consequence of your choice (inherited from Fedora Core 5's choice) of POSIX compliance. This is becoming a FAQ; see my reply on this same subject from last week: http://lists.gnu.org/archive/html/bug-coreutils/2006-09/msg00035.html Just for the record, I was hit with this too; when I built 5.97 across our supported platforms (about nine combinations of hardware and OS), a script using the old '-#'/'+#' syntax broke. I added '-n' to it, but that in turn caused it to break with several non-GNU versions of head/tail that don't recognize '-n'; IOW, it broke compatibility with non-GNU versions of these utilities. I haven't re-tested with 6.x, but for now what I've been doing is sticking with '-n' and requiring this particular script to use GNU head/tail. After all, it's *SO* much easier to write portable scripts when all the platforms you run the script on have not only the same GNU toolchain, but the same *versions* of GNU tools :-). -- Matthew Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Coretutils tail command no longer correctly accepting +2 as a parameter
Mike Frysinger wrote: On Friday 15 September 2006 10:48, mwoehlke wrote: Just for the record, I was hit with this too; when I built 5.97 across our supported platforms (about nine combinations of hardware and OS), a script using the old '-#'/'+#' syntax broke. I added '-n' to it, but that in turn caused it to break with several non-GNU versions of head/tail that don't recognize '-n'; IOW, it broke compatibility with non-GNU versions of these utilities. wrong; this is not a GNU issue ... go complain to the POSIX people who write the specs that coreutils [correctly] follows Is is too a GNU issue! It's not POSIX's fault that you're the only ones that can follow their standards correctly! ;-) And in case I failed to make it clear (which it seems I did; sorry), I'm not complaining (or even asking for anything - nope, not even an explanation); I'm just making an observation about this change, as I said originally, for the record. I haven't re-tested with 6.x, but for now what I've been doing is sticking with '-n' and requiring this particular script to use GNU head/tail. After all, it's *SO* much easier to write portable scripts when all the platforms you run the script on have not only the same GNU toolchain, but the same *versions* of GNU tools :-). you might be able to get away with using sed in some places ... `head -10` == `head -n 10` == `sed -n 1,+9p` -mike Actually, I think I'd switched from sed to head/tail (because I have to suspect head/tail are faster) when I started running into this. :-) Anyway, no worries, I know how to come up with work-arounds; for now, as I said, my solution is use GNU head/tail (it's an internal script, so I can get away with that). I'm just taking notes out loud. -- Matthew Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.1: needs 'ls' patch (bug #15043)
Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to mwoehlke on 8/31/2006 10:18 AM: Look more closely at the code. The reason linux was failing was because it was not doing enough work, because the d_type shortcut let it skip a stat where one was needed. Platforms that did not have the bug are not doing extra work, because they have already done the stat (not having a d_type shortcut to rely on). So #ifdef'ing on linux is not the right approach, and Jim's patch was appropriate. Ok, so if I am understanding correctly, you are saying that on not-Linux, one of the other conditions in the 'if' will always cause the block to be evaluated? The bug in coloring directories according to their mode bits is that you need to know the mode bits. The only way to get mode bits is to call [l]stat. On newer Linux, and any other OS that provides d_type in readdir, the bug was that we were not calling stat because readdir's d_type tells us it is a directory, we know what to color it. On other platforms, like cygwin, that do not provide d_type, we had already called stat to figure out whether the file is a directory, so we already had the mode bits. The bug, then, was that Linux exposed a flaw in our optimization logic, but the same flaw is present on any other system with d_type - namely, if we know that a readdir entry is a directory, we STILL need a stat when coloring directories according to mode bits. Ultimately, the correct behavior is that for ALL platforms, coloring directories requires a stat at some point or another, and it was not a Linux-specific bug (it just so happened that Linux was the only platform you tested that had d_type and thus showed the bug). Conditionalizing your fix on __linux__ would have been wrong, had some other platform come up to speed and implemented a reliable d_type. Right, thanks for the explanation! -- Matthew 73% of all statistics are made up on the spot. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: md5sum extra option --silent request
Jon Grant wrote: Could an extra option be added to md5sum to only display file sums which don't fail verification when checking? Wouldn't that be 'only display sums that *DO* fail'? Especially given your description below? One of these statements is wrong; please clarify which you meant. :-) For example the addition of this extra argument -s, --silent only report errors Then we can check with md5sum -c -s I would be happy to code this and submit a patch if you would be happy with the feature? While you're at it, how about a feature to also silently ignore files that don't exist when checking against a checksum file? This would be useful when downloading parts of a project (say, KDE) that provides a monolithic list of checksums to easily get a 'success' or 'failure', instead of having to parse out failures due to missing files. I might be able to help out with said feature, so like you, Jon, I'm soliciting comments... -- Matthew 73% of all statistics are made up on the spot. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.1: needs 'ls' patch (bug #15043)
Eric Blake wrote: According to mwoehlke on 8/28/2006 9:58 AM: I don't see why the behavior of 'ls' should depend on whether the Linux kernel is used. Shouldn't coreutils 'ls' behave the same way on FreeBSD or Solaris? The *old* behavior depends on the kernel. Although I can't vouch for FreeBSD, I tested on Solaris (both SPARC 2.6 and x86 10) and several other platforms, and in 5.97 / 6.1, Linux was the *only* platform I tested on which it did not work. All of which is in the Savannah comments. I #ifdef'd the change to avoid doing unnecessary work on platforms that work correctly without the extra call. Look more closely at the code. The reason linux was failing was because it was not doing enough work, because the d_type shortcut let it skip a stat where one was needed. Platforms that did not have the bug are not doing extra work, because they have already done the stat (not having a d_type shortcut to rely on). So #ifdef'ing on linux is not the right approach, and Jim's patch was appropriate. Ok, so if I am understanding correctly, you are saying that on not-Linux, one of the other conditions in the 'if' will always cause the block to be evaluated? -- Matthew We apologize for the inconvenience. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils 'rm /' incompatibility with 2006-06-30 draft POSIX
Paul Eggert wrote: The 2006-06-30 draft of POSIX has this new requirement for 'rm': [snip] * The check for root's dev and ino is done recursively, but surely it should be done only at the top level? (I'm not sure why it's done recursively now.) The POSIX requirement talks only about the top level, and I don't see how you could recurse to the root. 'man mount', see '--bind' and '--rbind' -- Matthew We apologize for the inconvenience. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Suggested change to tee manpage to show usefulness
Jim Meyering wrote: The Wanderer [EMAIL PROTECTED] wrote: Jim Meyering wrote: ... It sounds like you don't like some aspect of the mailing list configuration. If you provide details, with suggestions for how and why to change it, we might be able to help. I appreciate the attitude, but frankly, I doubt it. The policy to which I object is the practice of not automatically directing replies to list messages back to the list - that is, the practice of not putting the list address in the Reply-To header. Oh, *that*. Even if I wanted to change that setting, I'm pretty sure that doing so would cause more problems than it would solve. FWIW, I'm subscribed to lists on four groups, and only KDE appears to override 'Reply-To:' (but I guess that means that there is precedent). If you really can't deal with *this* list not doing so, then I suggest news.gmane.org. -- Matthew Now where did I put my hippo? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.1: needs 'ls' patch (bug #15043)
Mike Frysinger wrote: On Friday 25 August 2006 11:14, mwoehlke wrote: Ok, thanks. I a: wasn't sure of a macro that would be defined on Linux (is there a list of these things anywhere? echo | gcc -E -dD - -mike Thanks! Unfortunately it doesn't seem to work with all non-GNU compilers, but it's still really useful. :-) -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.1: needs 'ls' patch (bug #15043)
Paul Eggert wrote: mwoehlke [EMAIL PROTECTED] writes: If #ifdef is OK, this should do it (works for me with 5.97 and 6.1): As I said, I don't really understand dircolors (but I'll go ahead and remark anyway :-). I don't see why the behavior of 'ls' should depend on whether the Linux kernel is used. Shouldn't coreutils 'ls' behave the same way on FreeBSD or Solaris? The *old* behavior depends on the kernel. Although I can't vouch for FreeBSD, I tested on Solaris (both SPARC 2.6 and x86 10) and several other platforms, and in 5.97 / 6.1, Linux was the *only* platform I tested on which it did not work. All of which is in the Savannah comments. I #ifdef'd the change to avoid doing unnecessary work on platforms that work correctly without the extra call. -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Building coreutils in Linux From Scratch
Paul Eggert wrote: mwoehlke writes: I'd like to jump in and make a comment here... I have coreutils (5.97) built on nine different platforms, but haven't even attempted to tackle procps as it is not auto*-based (and so far I have not been motivated to track down how to set up the build correctly, much less chase down bugs and build errors). Unless procps is fixed/improved, dropping these from coreutils means - from my POV - that they will be gone entirely. I know of no plans do drop them. That was the impression I got from Matthew Burgess' post; apparently that is non-authoritative? 'uptime' is a bit of a curiosity. On my platform (Debian stable) coreutils 'uptime' does its work with fewer system calls than procps 'uptime', so I don't know why anyone would prefer procps uptime. (Maybe someone else can chime in.) For 'kill', most people use Bash's 'kill', not coreutils's or procps's, so they probably don't care about 'kill' one way or another. At some point I was planning to merge coreutils 'kill' back into Bash but it's low priority. A good point, however a number of people around here use csh instead of bash, so I think it is still valuable (to me, anyway). 'su' is the only one we're thinking of dropping from coreutils. Do you use coreutils 'su'? 'su' is so intertangled with security gorp that these days it's pretty hard to port separately from the rest of the gorp. Doesn't look like it; it seems 'su' didn't get built on *any* of the systems I built coreutils on (even Linux? ...but I might have done that intentionally and just forgot). At any rate, I know 'su' is problematic and don't object to dropping that one. Certainly not if you're only dropping it from non-Linux builds (since it sounds like some other people would mind it going away entirely). -- Matthew '$ time make world' - real 5d:14h:37m:5.291s user 0m:0.000s sys 4d:2h:14m:43.712s ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.1: needs 'ls' patch (bug #15043)
Mike Frysinger wrote: On Thursday 24 August 2006 17:03, mwoehlke wrote: https://savannah.gnu.org/bugs/?func=detailitemitem_id=15043 Is this going to get fixed, or what? There is a trivial fix available, it just needs someone that knows how to make it 'Linux-only'. #if __linux__ foo #endif -mike Ok, thanks. I a: wasn't sure of a macro that would be defined on Linux (is there a list of these things anywhere? Preferably covering most major platforms?), and b: wasn't sure if people here appreciated such patches. If #ifdef is OK, this should do it (works for me with 5.97 and 6.1): *** ls.c.old2006-08-25 08:10:54.0 -0700 --- ls.c2006-08-25 08:12:49.0 -0700 *** *** 2555,2560 --- 2555,2563 if (command_line_arg || format_needs_stat + #ifdef __linux__ + || (type == directory print_with_color) + #endif || (print_inode (inode == NOT_AN_INODE_NUMBER /* When dereferencing symlinks, the inode must come from -- Matthew '$ time make world' - real 5d:14h:37m:5.291s user 0m:0.000s sys 4d:2h:14m:43.712s ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Building coreutils in Linux From Scratch
Matthew Burgess wrote: We could just as easily patch procps to prevent it from installing its versions of those two programs, but as we're preventing installation of `su' as it is, it made sense to suppress coreutils kill and uptime in the same patch. I'd like to jump in and make a comment here... I have coreutils (5.97) built on nine different platforms, but haven't even attempted to tackle procps as it is not auto*-based (and so far I have not been motivated to track down how to set up the build correctly, much less chase down bugs and build errors). Unless procps is fixed/improved, dropping these from coreutils means - from my POV - that they will be gone entirely. -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils-6.1: needs 'ls' patch (bug #15043)
https://savannah.gnu.org/bugs/?func=detailitemitem_id=15043 Is this going to get fixed, or what? There is a trivial fix available, it just needs someone that knows how to make it 'Linux-only'. I've tested the fix against 5.97. -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Building coreutils in Linux From Scratch
Mike Frysinger wrote: On Thursday 24 August 2006 15:33, mwoehlke wrote: Matthew Burgess wrote: We could just as easily patch procps to prevent it from installing its versions of those two programs, but as we're preventing installation of `su' as it is, it made sense to suppress coreutils kill and uptime in the same patch. I'd like to jump in and make a comment here... I have coreutils (5.97) built on nine different platforms, but haven't even attempted to tackle procps as it is not auto*-based (and so far I have not been motivated to track down how to set up the build correctly, much less chase down bugs and build errors). Unless procps is fixed/improved, dropping these from coreutils means - from my POV - that they will be gone entirely. the procps maintainer will never accept autotools (his words, not mine) ... i sent him a patch to autotool the build system and it was rejected ;) -mike I can understand that given that it is only for Linux... but that means that procps will likely only, ever, be supported on Linux, which is unfortunate. (And yes, I know that is likely to be true anyway.) Which, as I said, is IMO a good reason to keep 'kill' and 'uptime' (especially 'uptime') in coreutils; otherwise you are essentially removing software packages. -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
