Hi,
I'm getting a build error with coreutils-8.3. version 8.2 builds fine
with the same toolset/glibc releases. The error is as follows:
CC dup-safer.o
CC exclude.o
In file included from mbuiter.h:106,
from exclude.c:38:
mbchar.h:
On Sat, Jan 9, 2010 at 12:36 AM, Andreas Schwab sch...@linux-m68k.org wrote:
Roel Kluin roel.kl...@gmail.com writes:
unicode characters 0x24, 0x40 and 0x60 were not considered as valid
characters.
$ /usr/bin/printf '\u0024\u0040\u0060\n'
$...@`
$ /usr/bin/printf --version
printf (GNU
On Saturday 09 January 2010 03:58:02 Chris Clayton wrote:
I'm getting a build error with coreutils-8.3. version 8.2 builds fine
with the same toolset/glibc releases. The error is as follows:
gcc version is 4.4.3 20100105 (prerelease). glibc is 2.7.
seems to be an issue with =glibc-2.9. at
Mike Frysinger wrote:
On Saturday 09 January 2010 03:58:02 Chris Clayton wrote:
I'm getting a build error with coreutils-8.3. version 8.2 builds fine
with the same toolset/glibc releases. The error is as follows:
gcc version is 4.4.3 20100105 (prerelease). glibc is 2.7.
seems to be an
On Friday 08 of January 2010 11:08:48 Jean Philippe EIMER wrote:
Compiling coreutils 8.3 fails at ls.c, with gcc 4.4.2, glibc 2.11.1 and
kernel 2.6.32.3 :
In file included from /usr/include/bits/sigcontext.h:28,
from /usr/include/signal.h:339,
from
On Saturday 09 of January 2010 21:00:56 Kamil Dudka wrote:
It looks to me like https://bugzilla.redhat.com/483548 - it has been
discussed several times on this mailing list. You can find it going through
the archive.
As the problem still persists on some systems, it drives me to another idea.
Jim Meyering wrote:
Eric Blake wrote:
According to Voelker, Bernhard on 1/8/2010 7:40 AM:
Hello,
`make check` failed for 2 of 357 tests here:
openSUSE 10.3 (X86-64) (inside a 11 hosted virtual machine)
kernel 2.6.9-023stab051.3-smp
gcc 4.2.1
CPU: Quad-Core AMD Opteron(tm)
Definitively, this is THE solution.
I upgraded libcap from 2.16 to 2.18, and coreutils compiles well now.
Thank you.
Le 09/01/2010 21:00, Kamil Dudka a écrit :
On Friday 08 of January 2010 11:08:48 Jean Philippe EIMER wrote:
Compiling coreutils 8.3 fails at ls.c, with gcc 4.4.2, glibc 2.11.1
Kamil Dudka wrote:
On Saturday 09 of January 2010 21:00:56 Kamil Dudka wrote:
It looks to me like https://bugzilla.redhat.com/483548 - it has been
discussed several times on this mailing list. You can find it going through
the archive.
As the problem still persists on some systems, it
The wchar.h-related build failure affects enough
people (libc-2.7..2.9-based systems) that I plan to make
an 8.4 release with minimal changes to fix that and any
other problem that crops up in the mean time.
On Saturday 09 of January 2010 22:40:08 Jim Meyering wrote:
I've added details (and * src/ls.c: ...) to the log.
Thanks for the amendment.
Kamil
Hi,
The recently introduced nproc utility outputs wrong result when run in
--all mode inside a /proc-less /sys-less GNU/Linux chroot on a system
with several CPUs. In this environment, nproc --all always outputs 1
while plain nproc outputs correct number of available CPUs.
The underlying
when --all fails for any reason, I think we should try with the number
of available processing units, at least it is a more accurate value than
return 1 (and document this behaviour).
Bruno, Jim, what do you think?
Cheers,
Giuseppe
Dmitry V. Levin l...@altlinux.org writes:
Hi,
The
On 10/01/10 01:14, Giuseppe Scrivano wrote:
when --all fails for any reason, I think we should try with the number
of available processing units, at least it is a more accurate value than
return 1 (and document this behaviour).
Bruno, Jim, what do you think?
Just to summarize what's happening
14 matches
Mail list logo
