Re: coreutils-6.3 on MacOS X

Paul Eggert wrote: > > at-func.c:39: warning: implicit declaration of function `lchown' > > dirchownmod.c:102: warning: implicit declaration of function `lchown' > > (lchown is not provided by the system; gnulib's substitute is used.) > > mkstemp-safer.c:34: warning: implicit declaration of functio

coreutils CVS on NetBSD 3.0

Hi, The testing results of coreutils CVS as of Saturday, on NetBSD 3.0: if gcc -std=gnu99 -I. -I. -I.-Wall -I/home/bruno/gnu/include -g -O2 -MT filemode.o -MD -MP -MF ".deps/filemode.Tpo" -c -o filemode.o filemode.c; then mv -f ".deps/filemode.Tpo" ".deps/filemode.Po"; else rm -f ".dep

Re: coreutils-6.3 on Linux 2.4 kernel

Paul Eggert wrote: > However, I can't test this easily since I don't have such a kernel. > ... > It's not an ideal fix, but it's the best I could > think of offhand. Thanks! coreutils + gnulib from Saturday now pass "make check" entirely fine on the Linux-2.4.21 machine. Bruno

Re: coreutils-6.3 on MacOS X

Bruno Haible <[EMAIL PROTECTED]> wrote: > pathchk.c:203: warning: missing braces around initializer > pathchk.c:203: warning: (near initialization for `mbstate.__mbstate8') > > Here the problem is: > mbstate_t mbstate = {0}; > ISO C 99 guarantees only that mbstate_t is not an array type; it c

Re: coreutils-6.3 on MacOS X

Bruno Haible <[EMAIL PROTECTED]> wrote: ... > In file included from lchown.c:26: > stat-macros.h:26:4: #error "you must include before including > this file" > lchown.c: In function `lchown': > lchown.c:37: error: storage size of `stats' isn't known > lchown.c:39: warning: implicit declaration of

Re: coreutils-6.3 on MacOS X

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/9/2006 5:50 AM: > Thanks. > I've checked in that change: > > 2006-10-09 Jim Meyering <[EMAIL PROTECTED]> > > * lchown.c: Include before "stat-macros.h". > Patch from Bruno Haible. Why not instead fix st

symlink calculation in bootstrap script

Hi, Here's a patch to lift a few restrictions in the bootstrap script. 2006-10-08 Bruno Haible <[EMAIL PROTECTED]> * bootstrap (func_relativize): New function, taken from gnulib-tool. (symlink_to_gnulib): Use it. *** bootstrap.bak 2006-10-07 15:40:13.0 +0200 ---

make it possible to avoid symlinks in coreutils' bootstrap

Hi Paul, The fact that coreutils' bootstrap script creates symlinks can be an annoyance: - Creating self-contained tarballs requires extra effort. - On my systems, I have a date as part of the gnulib directory name, and rename it each time I update. In such a situation, the symlinks br

Re: coreutils-6.3 on MacOS X

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Jim Meyering on 10/9/2006 5:50 AM: >> Thanks. >> I've checked in that change: >> >> 2006-10-09 Jim Meyering <[EMAIL PROTECTED]> >> >> * lchown.c: Include before "stat-macros.h". >> Patch from Bruno Haible. > > Why not instead fix sta

Re: coreutils-6.3 on MacOS X

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/9/2006 6:40 AM: >> Why not instead fix stat-macros.h to include ? Then future >> users of "stat-macros.h" don't have to worry about this portability trap. > > Because there have been problems with systems for which >

Re: coreutils-6.3 on MacOS X

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Jim Meyering on 10/9/2006 6:40 AM: >>> Why not instead fix stat-macros.h to include ? Then future >>> users of "stat-macros.h" don't have to worry about this portability trap. >> >> Because there have been problems with systems for which >> can

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 mainstre

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: ./con

[date] ISO-8601 date format

Hello, To convert a date into the full ISO-8601 format one can do this: $ date --iso-8601=seconds --date "sun oct 1 5:45:02PM" It will correctly returns: 2006-10-01T17:45:02+0200 But when we want to convert a ISO-8601 formated date into a man readable format: $ date --date "20

Re: [date] ISO-8601 date format

"JL Lacroix" <[EMAIL PROTECTED]> writes: > $ date --date "2006-10-01T17:45:02+0200" > Returns > date: invalid date `2006-10-01T17:45:02+0200' > > Obviously, the full ISO-8601 format is not accepted as date input format. > > Any work around? Replace the T with a space. Andreas. -- And

Re: [date] ISO-8601 date format

JL Lacroix wrote: > To convert a date into the full ISO-8601 format one can do this: > > $ date --iso-8601=seconds --date "sun oct 1 5:45:02PM" The NEWS for the latest CVS says: date accepts the new option --rfc-3339=TIMESPEC. The old --iso-8602 (-I) option is deprecated; it still work

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-stand

[bug #17956] "sort" manual should mention that fields are numbered starting from 1

URL: Summary: "sort" manual should mention that fields are numbered starting from 1 Project: GNU Core Utilities Submitted by: None Submitted on: Monday 10/09/2006 at 18:33 UTC Categor

Re: coreutils-6.3 on MacOS X

Bruno Haible <[EMAIL PROTECTED]> writes: > Here the problem is: > mbstate_t mbstate = {0}; > ISO C 99 guarantees only that mbstate_t is not an array type; it could > be a scalar or pointer type. But that's OK. The initializer is valid C89 (and C99) even if mbstate_t is a scalar or pointer

Re: fix coreutils' "make distcheck": remove AC_CONFIG_LIBOBJ_DIR(lib)

Hello Jim, Eric, * Eric Blake wrote on Sat, Oct 07, 2006 at 07:41:02PM CEST: > According to Jim Meyering on 10/7/2006 10:06 AM: > > [cc'ing bug-automake, in case this is a bug. > > I was using both automake-1.9b and the latest from cvs. ] > [...] by using > AC_CONFIG_LIBOBJ_DIR(gnu), automake cr

Re: coreutils-6.3 on MacOS X

Paul Eggert <[EMAIL PROTECTED]> wrote: ... > This subject has come up a couple of times before. In > > I noted that glibc now sometimes uses the following style when the > type isn't known to be a structure or a scalar: > >

Re: symlink calculation in bootstrap script

Bruno Haible <[EMAIL PROTECTED]> writes: > Here's a patch to lift a few restrictions in the bootstrap script. It's nice to lift restrictions, but that patch adds about 8.5 seconds of CPU time and 11 seconds of real time to './bootstrap' on my platform, and unless I'm missing something the restric

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

Re: coreutils CVS on NetBSD 3.0

Bruno Haible <[EMAIL PROTECTED]> writes: > filemode.c:171: warning: implicit declaration of function `strmode' Thanks for reporting this. It's better to fix this in filemode.h, for the benefit of filemode's users, so I installed this into gnulib: 2006-10-09 Paul Eggert <[EMAIL PROTECTED]>

Re: make it possible to avoid symlinks in coreutils' bootstrap

Bruno Haible <[EMAIL PROTECTED]> writes: > Would you mind adding a --copy option to the bootstrap script? Roughly > like this? Good suggestion, yes. I installed the following somewhat-different patch, which is a bit more cautious about switching between a bootstrap with and without --copy. Also

Re: [date] ISO-8601 date format

[EMAIL PROTECTED] (Bob Proulx) writes: > Paul, Shouldn't that be iso-8601 instead of iso-8602 in the above? Yes, thanks, I installed this: 2006-10-09 Paul Eggert <[EMAIL PROTECTED]> * NEWS: Fix typo: iso-8602 -> iso-8601. Problem reported by Bob Proulx. --- NEWS.~1.438.~

Re: coreutils-6.3 on MacOS X

Paul Eggert wrote: > It causes "gcc -Wall" to issue a warning, but you can work around > this by appending -Wno-missing-braces. The warning that this kind of initializer (with or without the trailing comma) elicits with "gcc -W -Wall" on glibc systems is foo.c:3: warning: missing in

Re: [date] ISO-8601 date format

2006/10/9, Bob Proulx <[EMAIL PROTECTED]>: Basically fixed by the --rfc-3339 option for which you will need to upgrade to a 6.x release. Until then you will need to process the date format and reformat it before passing it back to date. Thanks. Using streamlined Debian distro on my servers, I