NSK/OSS compilation problems, continued
lib/mkdir-p.c needs: #ifndef HAVE_FCHMOD # define HAVE_FCHMOD 0 #endif (or maybe 'false' instead of '0'?) Looks like an oversight... -- Matthew Will your shell have salvation? Only if it's Bourne Again. ___ 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:
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
:-)
I'm afraid you'll have to get up to speed with them in order to do
reasonable development in this area. You don't have to port the
autotools to NSK(OSS); just run them on a GNU/Linux host, do a "make
dist" and then unpackage the tar image on NSK(OSS).
I was hoping someone else could slip in the 'configure needs to write a
replacement for HAVE_UNSIGNED_LONG_LONG_INT'. :-) I would have thought
this is a one-line, trivial change?
Anyway, this got me as far as sha512.c where the compiler croaked with:
Fundamentally the problem is that sha512 assumes a 64-bit unsigned
integer type, and you don't have one. I guess the best way to fix
this is to change coreutils to not build sha512 on hosts that don't
have uint64_t.
Well, the question was "am I ok telling coreutils to not build
sha512.c?". I'll take that as a "yes", thanks!
(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?)
I don't know what you mean by "NTP", but we're always interested in
ports to real hosts, and Tandem/NSK OSS qualifies as a real host in my
book. The thread is still live on
<http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00062.html>,
if that's what you mean.
Oops, I meant "NNTP"; I'm using gmane.org. What I meant was that I
expect the roots of the post to start being culled, but I guess I'll
just ignore that/live with it.
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
...
This indicates that our tests for sys/ioctl.h and sys/statvfs.h are
neglecting to include some prerequisite include files. I cannot
reproduce the problem with CVS coreutils on Solaris 10 (using Sun C
5.8), so I guess the problem is fixed now. If not, you'll have to
send us more info.
No, in *this* case (and it is a strange one), the problem is that
_TANDEM_SOURCE is not defined; not by missing headers. I can verify this
with:
$ CFLAGS=-D_TANDEM_SOURCE ./configure
...
checking sys/statvfs.h presence... yes
checking for sys/statvfs.h... yes
...
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
...
...but I don't feel that this is an ideal solution. I would prefer that
autoconf know that if it is on NSK/OSS ('#ifdef __TANDEM'), that
_TANDEM_SOURCE needs to be defined. I.e. I would add an early check that
would toss '-D_TANDEM_SOURCE' into CFLAGS, and of course use that value
as it goes on to try its test programs.
Meanwhile, however, I am going to keep going without to see what
individual sources trip over this, unless I hear agreement that autoconf
should be fixed. (I would guess this impacts quite a few packages, and
not just coreutils.)
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.
Can you give more information about this? What is _TANDEM_SOURCE
used for? You can check the files under /usr/include to find out.
If you see the aforementioned bug report, it must be defined for a
number of headers to compile correctly... including sys/types.h (see
next comment), and also sys/statvfs.h and sys/ioctl.h (see above).
For statvfs.h:
"/usr/include/sys/statvfs.h", line 50: error(114): identifier "u_long"
is undefined
What include file is supposed to define u_long? Use "grep -r u_long
/usr/include" to find out. Similary for ioctl.h.
sys/types.h defines u_*, but *only if _TANDEM_SOURCE is defined*. No
header in /usr/include defines this, but *all* of these test for it:
/usr/include/ctype.h
/usr/include/dirent.h
/usr/include/fcntl.h
/usr/include/fnmatch.h
/usr/include/limits.h
/usr/include/locale.h
/usr/include/netdb.h
/usr/include/netinet/in.h
/usr/include/nl_types.h
/usr/include/pwd.h
/usr/include/signal.h
/usr/include/stdio.h
/usr/include/stdlib.h
/usr/include/string.h
/usr/include/stropts.h
/usr/include/sys/ipc.h
/usr/include/sys/socket.h
/usr/include/sys/types.h
/usr/include/sys/uio.h
/usr/include/sys/un.h
/usr/include/sys/wait.h
/usr/include/termios.h
/usr/include/unistd.h
/usr/include/wchar.h
I'm attaching sys/types.h so you can take a look, but just in case the
horse isn't dead enough yet, /plea
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: 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 . That is a no-no nowadays, since 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
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: 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 , then , then , due to 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: [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: 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
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 . That is a no-no nowadays, since 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: coreutils 6.3 on Tru64 - just plain broken, or...?
Paul Eggert wrote: mwoehlke <[EMAIL PROTECTED]> writes: things went badly until I removed the #define for intmax_t from config.h. That's not a good sign. In what way did they go badly, exactly? What diagnostics did you get? 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 -^ cc: Error: xstrtol.c, line 53: In this declaration, the type of "strtoimax" is not compatible with the type of a previous declaration of "strtoimax" at line number 1039 in file ./inttypes.h. (notcompat) intmax_t strtoimax (); -^ cc: Warning: xstrtol.c, line 89: In this declaration, parameter 4 has a different type than specified in an earlier declaration of this function. (mismatparam) __xstrtol (const char *s, char **ptr, int strtol_base, ^ cc: Error: xstrtol.c, line 89: In this declaration, the type of "xstrtoimax" is not compatible with the type of a previous declaration of "xstrtoimax" at line number 48 in file xstrtol.h. (notcompat) __xstrtol (const char *s, char **ptr, int strtol_base, ^ make[2]: *** [xstrtoimax.o] Error 1 make[2]: Leaving directory `/home/install/gnu/src/coreutils-6.3-alpha_osf/lib' ...this all went away if I took out the redefinition of intmax_t. It appears to be conflicting with the definition in lib/stdint[_].h. -- 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: coreutils 6.3 on Tru64 - just plain broken, or...?
Paul Eggert wrote: mwoehlke <[EMAIL PROTECTED]> writes: ...is anyone else trying to build on Tru64? I'm using 4.0G to build, and I have a LOT of problems. Yes, people build coreutils on Tru64, though 4.0G (released 2000-05) is getting a bit old. Have you applied all the relevant patches? See <http://h30097.www3.hp.com/docs/patch/>. This isn't exactly "my" box; applying patches to it really isn't something I can do on a whim. If we drop 4.0* I can move to our 5.x boxes, but for now the box I'm building on is the same one we use to build our products, so I have to stick with it as-is. (At least it isn't the even-older 4.0F which is supposed to be what we actually *support*, and doesn't have [v]snprintf()!) -- 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: coreutils 6.3 on Tru64 - just plain broken, or...?
Paul Eggert wrote: mwoehlke <[EMAIL PROTECTED]> writes: 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. I installed this patch to Autoconf to try to address this problem. [snip] Thanks! However, unless you also have a patched 'configure' for me also, I'll just take your word for it. :-) -- 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
14
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
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: 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
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 ./sp
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
Re: make check "failure" on Itanium HPUX
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?) Same versions of bash and make here (both built from clean sources). -- Matthew "I don't question your existence -- God" (seen on a church billboard) Making check in lib make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/lib' ./t-fpending > /dev/null make check-am make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/lib' make[2]: Nothing to be done for `check-am'. make[2]: Leaving directory `/home/install/gnu/src/coreutils-6.3/lib' make[1]: Leaving directory `/home/install/gnu/src/coreutils-6.3/lib' Making check in src make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/src' rm -rf progs-readme progs-makefile echo [ 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 nl od paste pr ptx sha1sum sha224sum sha256sum sha384sum sha512sum shuf sort split sum tac tail tr tsort unexpand uniq wc basename date dirname echo env expr factor false hostname id kill logname pathchk printenv printf pwd seq sleep tee test true tty whoami yes base64 uname chroot hostid nice pinky users who uptime stty df groups chroot df hostid nice pinky stty su uname uptime users who \ | tr -s ' ' '\n' | sed -e 's,$,,' \ | LC_ALL=C sort -u > progs-makefile && \ sed -n '/^The programs .* are:/,/^[a-zA-Z]/p' ../README \ | sed -n '/^ */s///p' | tr -s ' ' '\n' > progs-readme diff progs-makefile progs-readme && rm -rf progs-readme progs-makefile diff: memory exhausted make[1]: *** [check-README] Error 2 cd .; grep '^# *define *S_IS' lbracket.c base64.c basename.c cat.c chgrp.c chown-core.c chmod.c chown.c chown-core.c chroot.c cksum.c comm.c cp.c copy.c cp-hash.c csplit.c cut.c date.c dd.c df.c ls.c ls-dir.c dircolors.c dirname.c du.c echo.c env.c expand.c expr.c factor.c false.c fmt.c fold.c install.c copy.c cp-hash.c head.c hostid.c hostname.c id.c join.c kill.c link.c ln.c logname.c ls.c ls-ls.c md5sum.c mkdir.c mkfifo.c mknod.c mv.c copy.c cp-hash.c remove.c nice.c nl.c nohup.c od.c paste.c pathchk.c pinky.c pr.c printenv.c printf.c ptx.c pwd.c readlink.c rm.c remove.c rmdir.c seq.c setuidgid.c md5sum.c md5sum.c md5sum.c md5sum.c md5sum.c shred.c shuf.c sleep.c sort.c split.c stat.c stty.c su.c sum.c sync.c tac.c tail.c tee.c test.c touch.c tr.c true.c tsort.c tty.c uname.c unexpand.c uniq.c unlink.c uptime.c users.c ls.c ls-vdir.c wc.c who.c whoami.c yes.c && exit 1 || : cd .; grep st_blocks lbracket.c base64.c basename.c cat.c chgrp.c chown-core.c chmod.c chown.c chown-core.c chroot.c cksum.c comm.c cp.c copy.c cp-hash.c csplit.c cut.c date.c dd.c df.c ls.c ls-dir.c dircolors.c dirname.c du.c echo.c env.c expand.c expr.c factor.c false.c fmt.c fold.c install.c copy.c cp-hash.c head..c hostid.c hostname.c id.c join.c kill.c link.c ln.c logname.c ls.c ls-ls.c md5sum.c mkdir.c mkfifo.c mknod.c mv.c copy.c cp-hash.c remove.c nice.c nl.c nohup.c od.c paste.c pathchk.c pinky.c pr.c printenv.c printf.c ptx.c pwd.c readlink.c rm.c remove.c rmdir.c seq.c setuidgid.c md5sum.c md5sum.c md5sum.c md5sum.c md5sum.c shred.c shuf.c sleep.c sort.c split.c stat.c stty.c su.c sum.c sync.c tac.c tail.c tee.c test.c touch.c tr.c true.c tsort.c tty.c uname.c unexpand.c uniq.c unlink.c uptime.c users.c ls.c ls-vdir.c wc.c who.c whoami.c yes.c && exit 1 || : cd .; grep '^# *define .*defined' lbracket.c base64.c basename.c cat.c chgrp.c chown-core.c chmod.c chown.c chown-core.c chroot.c cksum.c comm.c cp.c copy.c cp-hash.c csplit.c cut.c date.c dd.c df.c ls.c ls-dir.c dircolors.c dirname.c du.c echo.c env.c expand.c expr.c factor.c false.c fmt.c fold.c install.c copy.c cp-hash.c head.c hostid.c hostname.c id.c join.c kill.c link.c ln.c logname.c ls.c ls-ls.c md5sum.c mkdir.c mkfifo.c mknod.c mv.c copy.c cp-hash.c remove.c nice.c nl.c nohup.c od.c paste.c pathchk.c pinky.c pr.c printenv.c printf.c ptx.c pwd.c readlink.c rm.c remove.c rmdir.c seq.c setuidgid.c md5sum.c md5sum.c md5sum.c md5sum.c md5sum.c shred.c shuf.c sleep.c sort.c split.c stat.c stty.c su.c sum.c sync.c tac.c tail.c tee.c test.c touch.c tr.c true.c tsort.c tty.c uname.c unexpand.c uniq.c unlink.c uptime.c users.c ls.c ls-vdir.c wc.c who.c whoami.c yes.c && exit 1 || : make[1]: Target `check'
make check "failure" on Itanium Linux
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: + echo + echo + mkdir dir-12144 + test kill = '[' + prog=kill + eval 'args=$kill_args' ++ args=13844 + ../../src/kill 13844 + : + rm -rf in-12144 in2-12144 out-12144 dir-12144 ./help-version: line 209: 13844 Terminated sleep 10m + rm -rf in-12144 in2-12144 dir-12144 out-12144 It looks like something is not absorbing an expected failure like it should. Any guesses? $ /bin/sh --version GNU bash, version 2.05.8(1)-release (ia64-redhat-linux-gnu) Copyright 2000 Free Software Foundation, Inc. $ make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for ia64-unknown-linux-gnu $ bash --version GNU bash, version 3.1.17(1)-release (ia64-unknown-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. $ echo $BASH_VERSION 3.1.17(1)-release -- 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: coreutils-6.3: c89 patch insufficent
Paul Eggert wrote: mwoehlke <[EMAIL PROTECTED]> writes: So, at least here, if c99 becomes a strict requirement, I won't be able to build on sparc Solaris at all, unless I can manage building gcc first. A couple of things. * First, coreutils doesn't require C99; it merely requires a few C99 features, like declarations after statements. GCC 3.2.3 should be fine. I'm still unclear on why the main source doesn't simply support strict c89 compilers, given that a patch is so easily available. (Might have wanted to mention that in README.) * Second, I'd be surprised if the latest GCC doesn't build on Solaris 7. Certainly its installation instructions talk about Solaris 7. (I long ago lost my last Solaris 7 host, so I can't easily check this myself.) I haven't tried; building gcc is not something I particularly want to do if I can avoid it. Plus I would prefer to use either native compilers across the board, or gcc across the board, and to go gcc I would have to build it on some eight different platforms (including the infamous OSS and our Itanium Linux box which currently has the gcc 2.96 abomination). So I wouldn't worry so much about this issue; it's not as serious as it might seem. I'm not worried, that's why I put "FYI" at the beginning of my post. :-) Nor did I say it was serious. Nope, just informative. -- 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: coreutils-6.3: c89 patch insufficent
Michael Deutschmann wrote: coreutils-6.3 includes a patch, c99-to-c89.diff, to allow it to be compiled on platforms that don't support declarations after statements. However, this patch is not sufficent -- I had to fix two other areas to get coreutils to compile under GCC 2.95.3. I've appended my fixes. They are to be applied after the existing c99-to-c89.diff. [snip patch] Thanks for those. FYI: Since I remember having a discussion on the wisdom of requiring c99, I'll mention that I have since discovered that our sparc Solaris platform (which is 2.7, that being the oldest version on which we still support products) does not have a c99. In fact, other than gcc 3.2.3 which we have built for 2.8 (and doesn't work on 2.7, if at all - configure complained 'header exists but is not usable' for apparently EVERY header that existed), I can't find that we have *any* c99 compiler for sparc. So, at least here, if c99 becomes a strict requirement, I won't be able to build on sparc Solaris at all, unless I can manage building gcc first. -- 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
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: 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: 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
Re: Dawrin- why does pinky SIGBUS
(Sigh. I sure wish gdb built (and worked) on Darwin, Apple's version
insists on invoking a broken csh that bitches about my modern LS_COLORS.)
Paul Eggert wrote:
mwoehlke <[EMAIL PROTECTED]> writes:
#0 0x90007260 in strlen ()
#1 0x9000d1d8 in strdup ()
#2 0x393c in canon_host_r (host=0xfffc , cherror=0x8248) at canon-host.c:74
This suggest that this code in canon-host.c:
hints.ai_flags = AI_CANONNAME;
status = getaddrinfo (host, NULL, &hints, &res);
if (!status)
{
retval = strdup (res->ai_canonname);
set status to 0, but res->ai_canonname was NULL. Can you verify
that this in fact happened?
(gdb)
69status = getaddrinfo (host, NULL, &hints, &res);
(gdb) step
70if (!status)
(gdb) print status
$1 = 0
(gdb) print *res
$2 = {
ai_flags = 0,
ai_family = 2,
ai_socktype = 2,
ai_protocol = 17,
ai_addrlen = 16,
ai_canonname = 0x0,
ai_addr = 0x30b720,
ai_next = 0x3009e0
}
(gdb)
Yup, that's what happened. getaddrinfo() broken?
Are you using the system getaddrinfo, or the one shipped with
coreutils?
Um... no idea? I un-tar'd, did './configure --prefix=mount>' and 'make'. So I'm using whatever that picks up? If it means
anything, when I 'step'd in gdb at the getaddrinfo call, it stepped over
rather than into (not that I entirely trust gdb 5.3 with Apple patches).
That said, given the address when I set a breakpoint there, I am
guessing it is the system getaddrinfo?
(gdb) break getaddrinfo
Breakpoint 1 at 0x9005492c
(gdb) run
Starting program: /home/install/gnu/alpha/src/coreutils-6.3/src/pinky
Reading symbols for shared libraries +.. done
Reading symbols for shared libraries . done
[snip]
Reading symbols for shared libraries . done
LoginName TTY Idle When Where
Breakpoint 1, 0x9005492c in getaddrinfo ()
(gdb) bt
#0 0x9005492c in getaddrinfo ()
#1 0x2bd8 in print_entry (utmp_ent=0xb8c0) at pinky.c:305
#2 0x2bd8 in print_entry (utmp_ent=0x18013b0) at pinky.c:305
#3 0x320c in scan_entries (n=2, utmp_buf=0x18013b0, argc_names=0,
argv_names=0xbb08) at pinky.c:476
#4 0x32a4 in short_pinky (filename=0x796c "/var/run/utmp",
argc_names=25170864, argv_names=0xbb08) at pinky.c:494
#5 0x3684 in main (argc=1, argv=0xbb04) at pinky.c:622
(gdb)
Honestly I have never used pinky so I don't really care.
It's a sign of problems in the library, though. It should
get fixed.
Clearly you talked me into it. :-)
--
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
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
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 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
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
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)
mwoehlke wrote: mwoehlke wrote: Jim Meyering wrote: mwoehlke <[EMAIL PROTECTED]> wrote: Jim Meyering wrote: mwoehlke <[EMAIL PROTECTED]> wrote: [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. Now, *that* is interesting. Would you please see if you can reproduce that using an rm binary built from coreutils-6.2? I couldn't, when using an hfs partition on Darwin 8.7.0. The core of rm was seriously revamped between coreutils-5.97 and 6.0. I plan to, as soon as I get a chance. FYI this was on an NFS mount so there might be some weird interaction with the NFS driver... although I've built coreutils 5.97 on almost a dozen platforms and Darwin (both x86 and PowerPC as I recall) is the only OS that's given me problems. I was unable to reproduce that. Tried both NFS and hfs. If you can, please give details asap. I expect to release coreutils-6.3 very soon. It'd be particularly useful to know how many files it removes at each iteration. Did you try with 5.97? I haven't tried 6.2 yet (will try to do that soon)... Ok, I just tried with the "latest" version you sent me (post-6.2, will-be-6.3 for the rest of the list) with the same results. Hmm, and Darwin on x86 seems OK? $ uname -srvmpio Darwin 8.6.1 Darwin Kernel Version 8.6.1: Tue Mar 7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386 i386 i386 iMac4,1 Darwin Ah, but it's also a much newer Darwin... so... I'm working on building test output (including verbose) for the entire suite for Darwin PowerPC (the same machine I did the last test on). Ok, I have the 'check' output; it is 6 files (one master, five individual failed tests with VERBOSE=yes) and 43k. .tar.bz2'd it is 6k. Which form is preferred? Also 'pinky' and 'help-version' failed; I couldn't figure out how to run these by themselves and figured these two probably weren't as important as the rm, cp, mv, and chmod failures (and the fifth was du). [snip previous output] -- 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)
mwoehlke wrote: Jim Meyering wrote: mwoehlke <[EMAIL PROTECTED]> wrote: Jim Meyering wrote: mwoehlke <[EMAIL PROTECTED]> wrote: [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. Now, *that* is interesting. Would you please see if you can reproduce that using an rm binary built from coreutils-6.2? I couldn't, when using an hfs partition on Darwin 8.7.0. The core of rm was seriously revamped between coreutils-5.97 and 6.0. I plan to, as soon as I get a chance. FYI this was on an NFS mount so there might be some weird interaction with the NFS driver... although I've built coreutils 5.97 on almost a dozen platforms and Darwin (both x86 and PowerPC as I recall) is the only OS that's given me problems. I was unable to reproduce that. Tried both NFS and hfs. If you can, please give details asap. I expect to release coreutils-6.3 very soon. It'd be particularly useful to know how many files it removes at each iteration. Did you try with 5.97? I haven't tried 6.2 yet (will try to do that soon)... Ok, I just tried with the "latest" version you sent me (post-6.2, will-be-6.3 for the rest of the list) with the same results. I'm working on building test output (including verbose) for the entire suite for Darwin PowerPC (the same machine I did the last test on). > [snip previous output] -- 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'?
Paul Eggert wrote: mwoehlke <[EMAIL PROTECTED]> writes: how safe is running 'make check' as root? In practice I think it's fairly safe. But if you're at all worried about it, I suggest running it under a virtual emulator. After all, the whole point of 'make check' is to find bugs, and what could a buggy program do when run as root? Hehe, well, since I don't have a virtual emulator (or certainly couldn't get one for all the systems I want to test), I think I'll skip this. I could probably run it on Linux but I trust others are already doing that. 2. I am expecting a number of failures. How should I report these? The output of "make check" is a good start. If a particular test fails, it might help to re-run that verbosely. E.g., cd tests/mv VERBOSE=yes make TESTS=no-target-dir check Will do. Is it OK to bzip2 the results? Remember I expect to have several (as many as 10) of these! to what extent will I have to chase down bugs myself (or should I post results first, and go from there)? In some cases the fixes will be obvious. In others, I'm afraid you'll have to fix the bugs yourself and send us patches, as we don't have access to your machines. 3. How important are the local-file-system tests? That depends on how important local file systems are to applications running on the intended hosts. Ok... Is there a way to tell the tests to run in something other than the build directory? -- 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)
Jim Meyering wrote: mwoehlke <[EMAIL PROTECTED]> wrote: [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. Now, *that* is interesting. Would you please see if you can reproduce that using an rm binary built from coreutils-6.2? I couldn't, when using an hfs partition on Darwin 8.7.0. The core of rm was seriously revamped between coreutils-5.97 and 6.0. I plan to, as soon as I get a chance. FYI this was on an NFS mount so there might be some weird interaction with the NFS driver... although I've built coreutils 5.97 on almost a dozen platforms and Darwin (both x86 and PowerPC as I recall) is the only OS that's given me problems. I also saved the 'make check' output to take a look at, but I will probably roll a 6.2 before I take a serious look at that sort of thing (no need to chase down bugs that are already fixed, after all :-)). -- 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)
Jim Meyering wrote: mwoehlke <[EMAIL PROTECTED]> wrote: Jim Meyering wrote: mwoehlke <[EMAIL PROTECTED]> wrote: [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. Now, *that* is interesting. Would you please see if you can reproduce that using an rm binary built from coreutils-6.2? I couldn't, when using an hfs partition on Darwin 8.7.0. The core of rm was seriously revamped between coreutils-5.97 and 6.0. I plan to, as soon as I get a chance. FYI this was on an NFS mount so there might be some weird interaction with the NFS driver... although I've built coreutils 5.97 on almost a dozen platforms and Darwin (both x86 and PowerPC as I recall) is the only OS that's given me problems. I was unable to reproduce that. Tried both NFS and hfs. If you can, please give details asap. I expect to release coreutils-6.3 very soon. It'd be particularly useful to know how many files it removes at each iteration. Did you try with 5.97? I haven't tried 6.2 yet (will try to do that soon)... Um, actually, I am probably not going to try until someone can tell me how the *&($ to test the exit code of 'make check' after I've piped it through 'tee' :-) - tips would be most welcome! Easiest test is on coreutils itself... $ 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 $ rm --version rm (GNU coreutils) 5.97 Copyright (C) 2006 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. There is NO WARRANTY, to the extent permitted by law. Written by Paul Rubin, David MacKenzie, Richard Stallman, and Jim Meyering. $ ls coreutils-5.97 ls: coreutils-5.97: No such file or directory $ tar xzf coreutils-5.97.tar.gz $ find coreutils-5.97/ | wc -l 2788 $ rm -rf coreutils-5.97 rm: cannot remove directory `coreutils-5.97/m4': Directory not empty rm: cannot remove directory `coreutils-5.97/lib': Directory not empty $ find coreutils-5.97/ | wc -l 173 $ rm -rf coreutils-5.97 $ find coreutils-5.97/ | wc -l find: coreutils-5.97/: No such file or directory 0 $ (Again, NFS mount, about 60 GB, 28% used.) Anything else? I could also post the full list of files left over after the first try... -- 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
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: 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
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: [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
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: 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: 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: 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: -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: 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: 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: 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)
Jim Meyering wrote: Jim Meyering <[EMAIL PROTECTED]> wrote: mwoehlke <[EMAIL PROTECTED]> wrote: Mike Frysinger wrote: On Thursday 24 August 2006 17:03, mwoehlke wrote: https://savannah.gnu.org/bugs/?func=detailitem&item_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__ #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): Thanks for pursuing that. No #ifdef needed. Here's the patch I'll probably commit (destined for the trunk): I've checked this in on the trunk: [snip changelog] Thanks, although as noted elsewhere in this thread I still would have made it '#ifdef linux'. At any rate, it will work on Linux, and if it does extra work elsewhere, well, I can live with that. :-) -- 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: 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)
Mike Frysinger wrote: On Thursday 24 August 2006 17:03, mwoehlke wrote: https://savannah.gnu.org/bugs/?func=detailitem&item_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__ #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
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: 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
coreutils-6.1: needs 'ls' patch (bug #15043)
https://savannah.gnu.org/bugs/?func=detailitem&item_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
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
