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@
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'l
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
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 w
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
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
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
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 PRO
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 comp
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=
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 relev
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 cont
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
pa
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 ch
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 determi
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
...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
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 simil
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' j
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
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 merel
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 m
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" (whic
[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.
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
1048
(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_h
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
s
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 rep
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
. 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&#x
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 (a
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).
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 c
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
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, tha
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
[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
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 sys
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
l
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
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
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 &#x
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 con
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. :-)
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
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 t
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 kern
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 fra
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
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 dep
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
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 __l
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
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 core
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
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 he
56 matches
Mail list logo
