coreutils-7.1: make check fails under RHEL4

Hi all, I have just tried to build coreutils-7.1 on a RHEL4 (32bits) machine (building with GCC-4.1.2). "make check" fails on mv/part-symlink.log The end of the log contains: === + diff -u expected-7010 actual-7010 --- expected-7010

Re: coreutils-7.1: make check fails under RHEL4

Christophe LYON wrote: > Hi all, > > I have just tried to build coreutils-7.1 on a RHEL4 (32bits) machine > (building with GCC-4.1.2). > > "make check" fails on mv/part-symlink.log > The end of the log contains: > === > + diff -u expected

Re: coreutils-7.1: make check fails under RHEL4

You can do that by setting this envvar export CANDIDATE_TMP_DIRS=/some/other/partition/tmp and rerunning the test. Thanks for your prompt answer. Indeed it made the test pass. Thanks. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http

Re: root check failed for install-C-root

I've installed Ubuntu Studio into Xen using following image: http://cdimage.ubuntu.com/ubuntustudio/releases/jaunty/alpha-6/jaunty-alternate-amd64.iso kdu...@xen92:~/coreutils$ dpkg -l libc6\*| egrep -v "^un" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-c

[PATCH] maint: normalize leading-TAB indentation in Makefiles

No big deal, but slightly more consistent this way... >From e6d2d9479495dff8520e577c221d5195eb9bb48b Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 18 Mar 2009 12:20:32 +0100 Subject: [PATCH] maint: normalize leading-TAB indentation in Makefiles * maint.mk (sc_makefile_TAB_only_indentati

must use cp && rm as mv has no --no-preserve

Gentlemen, I have discovered I must use cp && rm as mv has no --no-preserve. # touch k; mv k /cf mv: failed to preserve ownership for `/cf/k': Operation not permitted # touch k; cp -a --no-preserve=owner k /cf && rm k You see, moving to VFAT, one will get that message under different mount owners

Re: [PATCH] Change 'sort' to handle fd exhaustion better.

Jim Meyering wrote: > Pádraig Brady wrote: ... > Thanks Pádraig, > And thanks to Paul and students. > > I've taken Paul's advice from the log about adding the test > from the other patch (and then removed that sentence from the log). > > I left the original patch intact for now. > > Of the followin

Re: ready for a bug-fix coreutils-7.2?

Jim Meyering wrote: I want to make a coreutils-7.2 release soon. There are still a few minor problems we haven't been able to reproduce (like the install-related test failure), and some portability problems, but there have been enough real bug fixes, http://git.sv.gnu.org/cgit/coreutils.git/p

coreutils 7.1.49-ebb9 FTB x86/Solaris

Tail of the build log below; what else would you like? make[3]: Entering directory `/home/install/gnu/build/i86_solaris/coreutils-7.1.49-ebb9/src' source='version.c' object='version.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../build-aux/depcomp \ cc -xc99=all -I. -I..

coreutils 7.1.49-ebb9 FTB sparc/Solaris, AIX

Tail of the build log below; what else would you like? (I'm retrying the sparc build with the Sun compiler; you /don't/ want to know what version of gcc this is ;-). But I don't expect success due to AIX having what looks like the same problem.) sparc/Solaris source='fsusage.c' obj

coreutils 7.1.49-ebb9 FTB risc/HP-UX

Tail of the build log below; what else would you like? (I've *no* idea how to pass options from cc to cpp :-(. I had a similar problem with ncurses and was unable to figure it out; I ended up having to break up what cpp was seeing to get past it.) cc -g -o cp cp.o copy.o cp-hash.o libver.

Re: coreutils 7.1.49-ebb9 FTB x86/Solaris

Matthew Woehlke wrote: Undefined first referenced symbol in file MAX uname.o Ah, I just found which is probably this issue. Any chance for an up

Re: ready for a bug-fix coreutils-7.2?

Matthew Woehlke wrote: I just fired off builds of 7.1.49-ebb9 on ten platforms. Given that I think there is at least one non-c99 compiler in that mix, the results will probably be... interesting :-). (More-so because I expect failures due to 'make check' being run on a known-flaky NFS volume.)

Re: misalignment in ls -l in fr_FR locale

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Samuel Thibault on 3/17/2009 3:36 PM: > Hello, > > $ ls -l > drwxr-xr-x 5 samy samy 4,0K mars 17 22:33 tmp/ > drwx-- 5 samy samy 4,0K févr. 12 18:20 u/ > > Because in the fr_FR locale abmon does not have a constant width, the > con

Re: ls - French translation of N_("%b %e %Y")

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding bug-gnulib] According to Stéphane Raimbault on 3/15/2009 5:09 AM: > Yes, it's a nice and easy solution but I've already tried to use %5b > without success on my system: > gcc 4.3.2 > glibc 2.8 (may 2008) > > gcc complains > warning: field wid

[bug #23647] 'id' not being built on OSX platforms

Follow-up Comment #2, bug #23647 (project coreutils): As I have said, both the bootvol and the pwd where things are built are both case-SENsitive, opposite to what you have been inferring all thru-out this bugreport. But I think I know what happened. On Tiger I did build GNU 'make' from CVS so

[bug #23647] 'id' not being built on OSX platforms

Follow-up Comment #3, bug #23647 (project coreutils): There have been several bug reports about the behavior of GNU make's --enable-case-insensitive-file-system configure option. This also affects MSYS, and was the cause of severe headaches for Autoconf, when make couldn't tell the difference be