bug#18060: coreutils-8.23: make check failure
On 21 Jul 2014 11:06, Bernhard Voelker m...@bernhard-voelker.de wrote: On 07/21/2014 05:39 AM, Chris Clayton wrote: On 07/20/14 22:46, Bernhard Voelker wrote: Would you mind switching mtab to be a symlink? Looking at the mount's man page, it seems that I will lose the user mount option. Fixed by Karel a few minutes ago: http://marc.info/?l=util-linux-ngm=140593135413670 http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=06716dffdc ;-) That's good, thanks. I'll report back on Wednesday. Have a nice day, Berny
bug#18060: coreutils-8.23: make check failure
Bernhard, Thanks for the reply. On 07/20/14 14:45, Bernhard Voelker wrote: src/df --out / $ src/df --out / Filesystem Type Inodes IUsed IFree IUse% 1K-blocks UsedAvail Use% File Mounted on /dev/sda3 ext4 3932160 304195 36279658% 61796348 32440776 26193460 56% // Chris
bug#8005: coreutils-8.10: make check failure
On Tuesday 08 February 2011, Jim Meyering wrote: Chris Clayton wrote: Firstly, please cc me on any reply because I'm not subscribed. I'm trying to build coreutils-8.10 but am getting a failure when I run make check. The failure occurs in check cp/sparse-fiemap and the log of that check is as follows: make check-TESTS make[1]: Entering directory `/home/chris/rpm/BUILD/coreutils-8.10/tests' make[2]: Entering directory `/home/chris/rpm/BUILD/coreutils-8.10/tests' FAIL: cp/sparse-fiemap == GNU coreutils 8.10: tests/test-suite.log == 1 of 1 test failed. .. contents:: :depth: 2 FAIL: cp/sparse-fiemap (exit: 1) Thanks for the report. I suspect that is merely a weakness in the test script and not a real problem, and in fact Pádraig Brady posted a patch that probably fixes it here: http://thread.gmane.org/gmane.comp.gnu.core-utils.announce/65/focus=867 Indeed, Pádraig's patch does fix the problem. :) Just in case, can you tell us about your system (i.e., uname -a) and file system type (df -T .) ? Just for the record I was building on 2.6.37 (and tried 2.6.38-rc4 too) and the fs was ext4 mounted via loop (by the test script) Thanks to Jim and Pádraig, Chris -- The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller
bug#8005: coreutils-8.10: make check failure
Hi,
Firstly, please cc me on any reply because I'm not subscribed.
I'm trying to build coreutils-8.10 but am getting a failure when I run make
check.
The failure occurs in check cp/sparse-fiemap and the log of that check is as
follows:
make check-TESTS
make[1]: Entering directory `/home/chris/rpm/BUILD/coreutils-8.10/tests'
make[2]: Entering directory `/home/chris/rpm/BUILD/coreutils-8.10/tests'
FAIL: cp/sparse-fiemap
==
GNU coreutils 8.10: tests/test-suite.log
==
1 of 1 test failed.
.. contents:: :depth: 2
FAIL: cp/sparse-fiemap (exit: 1)
++ initial_cwd_=/home/chris/rpm/build/coreutils-8.10/tests
++ fail=0
+++ testdir_prefix_
+++ printf gt
++ pfx_=gt
+++ mktempd_ /home/chris/rpm/build/coreutils-8.10/tests gt-sparse-fiemap.
+++ case $# in
+++ destdir_=/home/chris/rpm/build/coreutils-8.10/tests
+++ template_=gt-sparse-fiemap.
+++ MAX_TRIES_=4
+++ case $destdir_ in
+++ case $template_ in
unset TMPDIR
mktemp -d -t -p /home/chris/rpm/build/coreutils-8.10/tests
gt-sparse-fiemap.
+++ d=/home/chris/rpm/build/coreutils-8.10/tests/gt-sparse-fiemap.mg8J
+++ case $d in
+++ test -d /home/chris/rpm/build/coreutils-8.10/tests/gt-sparse-fiemap.mg8J
ls -dgo /home/chris/rpm/build/coreutils-8.10/tests/gt-sparse-fiemap.mg8J
tr S -
+++ perms='drwx-- 2 4096 Feb 8
19:45 /home/chris/rpm/build/coreutils-8.10/tests/gt-sparse-fiemap.mg8J'
+++ case $perms in
+++ test 0 = 0
+++ echo /home/chris/rpm/build/coreutils-8.10/tests/gt-sparse-fiemap.mg8J
+++ return
++ test_dir_=/home/chris/rpm/build/coreutils-8.10/tests/gt-sparse-fiemap.mg8J
++ cd /home/chris/rpm/build/coreutils-8.10/tests/gt-sparse-fiemap.mg8J
++ gl_init_sh_nl_='
'
++ IFS='
'
++ for sig_ in 1 2 3 13 15
+++ expr 1 + 128
++ eval 'trap '\''Exit 129'\'' 1'
+++ trap 'Exit 129' 1
++ for sig_ in 1 2 3 13 15
+++ expr 2 + 128
++ eval 'trap '\''Exit 130'\'' 2'
+++ trap 'Exit 130' 2
++ for sig_ in 1 2 3 13 15
+++ expr 3 + 128
++ eval 'trap '\''Exit 131'\'' 3'
+++ trap 'Exit 131' 3
++ for sig_ in 1 2 3 13 15
+++ expr 13 + 128
++ eval 'trap '\''Exit 141'\'' 13'
+++ trap 'Exit 141' 13
++ for sig_ in 1 2 3 13 15
+++ expr 15 + 128
++ eval 'trap '\''Exit 143'\'' 15'
+++ trap 'Exit 143' 15
++ trap remove_tmp_ 0
+ path_prepend_ ../src
+ test 1 '!=' 0
+ path_dir_=../src
+ case $path_dir_ in
++ cd /home/chris/rpm/build/coreutils-8.10/tests/../src
++ echo /home/chris/rpm/build/coreutils-8.10/src
+ abs_path_dir_=/home/chris/rpm/build/coreutils-8.10/src
+ case $abs_path_dir_ in
+
PATH=/home/chris/rpm/build/coreutils-8.10/src:/home/chris/rpm/BUILD/coreutils-8.10/src:/opt/kde3/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/usr/local/bin:/usr/local/sbin:/usr/java/bin:.:/usr/lib/qt3/bin:/home/chris/bin
+ create_exe_shims_ /home/chris/rpm/build/coreutils-8.10/src
+ case $EXEEXT in
+ return 0
+ shift
+ test 0 '!=' 0
+ export PATH
+ print_ver_ cp
+ test yes = yes
+ local i
+ for i in '$*'
+ env cp --version
cp (GNU coreutils) 8.10
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.
+ fiemap_capable_ .
+ df -T -t btrfs -t xfs -t ext4 -t ocfs2 -t gfs2 .
df: no file systems processed
+ require_root_
+ uid_is_privileged_
++ id -u
+ my_uid=0
+ case $my_uid in
+ NON_ROOT_USERNAME=nobody
++ id -g nobody
+ NON_ROOT_GROUP=65534
+ cwd=/home/chris/rpm/build/coreutils-8.10/tests/gt-sparse-fiemap.mg8J
+ skip=0
+ dd if=/dev/zero of=blob bs=32k count=1000
1000+0 records in
1000+0 records out
32768000 bytes (33 MB) copied, 0.0504067 s, 650 MB/s
+ mkdir mnt
+ mkfs -t ext4 -F blob
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
8000 inodes, 32000 blocks
1600 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=32768000
4 block groups
8192 blocks per group, 8192 fragments per group
2000 inodes per group
Superblock backups stored on blocks:
8193, 24577
Writing inode tables: 0/41/42/43/4done
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 23 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
+ mount -oloop blob mnt
+ cd mnt
+ echo test
+ test -s f
+ test 0 = 1
+ perl -e 1
++ seq 1 2 21
+ for i in '$(seq 1 2 21)'
+ for j in 1 2 31 100
+ perl -e 'BEGIN { $n = 1 * 1024; *F = *STDOUT }' -e 'for (1..1) { sysseek (*F,
$n, 1)' -e ' syswrite (*F, chr($_)x$n) or die $!}'
+ cp --sparse=always j1 j2
+ cmp j1 j2
+ filefrag -v j1
+ grep extent
j1: 2 extents found
+ filefrag -v
bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib version
Hi, On Friday 28 May 2010, Bruno Haible wrote: Hi, Chris Clayton wrote: but make check hangs when gnulib-tests/test-lock is run. The log showed that the hang occurred somewhere after the message Starting test_rwlock was output ... The only thing I can think of is that glibc is a bit old at 2.7, Using glibc-2.7 with a new kernel is unusual indeed. But the kernel people try hard not to break backward compatibility, and while glibc-2.7 is not as bleeding edge as linux 2.6.34, it is less than 3 years old. You can easily reduce the size of test-lock.c so that only one of the four tests is run. The next step will be to manually expand the macros from gnulib's lock.h, so that you get 100% POSIX compliant source code. With that, you could go to the glibc people and ask for help. But given that glibc-2.7 is old, you would need someone else to reproduce it also with a newer glibc. And personally I would guess it's a breakage in the new linux 2.6.34. But in order to isolate a bug in the multithread system calls, you need help of a some super hacker like Ulrich Drepper or Ingo Molnar. I built and installed glibc-2.11.1, this time against 2.6.33.4 kernel headers instead of the 2.6.26.x headers that were previously in /usr/src/linux. My idea was to just test the failing coreutils test application (test-lock), although, of course, a failure with this configuration may have been a false failure. Anyway. my system seems to be completely stable (although I do have the comfort of an archive of the old glibc-2.7-based system) and more importantly in the context of coreutils and gnulib, test-lock succeeds every time. I guess that could be a false success because all my apps are built against glibc-2.7 but running against glibc-2.11.1, but I've given my most frequently used applications a quite a good workout and everything seems to be working. On the face of it, the problem is in libpthread in glibc-2.7, especially as it went away when the coreutil test applications were built against libpth. Unless someone knows of a really good reason to do so, I'm not minded to chase this any longer. I have a workaround to build and test coreutils should I find that I need to revert to my glibc-2.7-based system, but for the time being at least, I think I'll stick with 2.11.1. Thanks for your help. So, can you trim down the testcase to something that fails with glibc-2.11 and submit that through the glibc bugzilla? Bruno -- The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller
bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib version
Hi Jim, I've done some more testing and the outcome is reported below. On Thursday 27 May 2010, Chris Clayton wrote: On Thursday 27 May 2010, Jim Meyering wrote: Chris Clayton wrote: I've just tried to build coreutils-8.5. The compilation finished OK, but make check hangs when gnulib-tests/test-lock is run. The log showed that the hang occurred somewhere after the message Starting test_rwlock was output, so I've added some additional debugging output to the test_rwlock function so that it now looks like: ... The final run shows that even if I leave the app to run for several minutes, it still fails to complete. I am running kernel 2.6.34 and my gcc is gcc (GCC) 4.4.5 20100525 (prerelease) (this week's 4.4 snapshot), although I get the same hang if I build and test with gcc-3.4.6. I'm not subscribed, so please cc me into any reply More than happy to provide any other information you need to solve this. Thanks for the report. Thanks for the reply. I cannot reproduce a problem with 2.6.34 and gcc-4.4.4. Is there anything else about your environment that might be unusual? The only thing I can think of is that glibc is a bit old at 2.7, but if I update to a later version, some of my apps stop working [e.g. midnight commander (mc)] and no matter how much recompiling I do, I can't get them to work again. The system started out (5 or 6 years ago) as Peanut Linux, which was a Slackware derivative amended to use rpm for package management. Nowadays, however, many, many packages have been added (KDE,OpenOffice, udev, cherokee - I could go on and on here) and upgraded. But it's finely tuned to the things I do with my computer. I tend to update packages as new versions become available, other than where I bump into dependency clashes or massive rebuild of packages. Can you reproduce that using the latest from git? If you're up to it, here's the build-from-git procedure: http://git.sv.gnu.org/cgit/coreutils.git/tree/README-hacking Had to build and install a few dependencies, but I've done the build-from-git thing and I get the same hang. The call to configure during the build is as follows: ./configure --prefix=/usr --disable-nls --mandir=/usr/man --infodir=/usr/info --disable-acl --disable-rpath --disable-xattr If I add --enable-threads=pth to the call to configure, test-lock runs successfuly ever time. If I make it --enable-threads=posix (or let it default to posix), test-lock will very occasionally succeed, but more often than not hangs as per my report above. If I define ENABLE_DEBUGGING as 1 in test-lock.c, test-lock succeeds regardless of the threading library that's used. I guess this all points to something like a thread sync problem in libpthread at glibc-2.7. However, it appears that the --enable-threads=blah setting only affects the test applications. Whatever I set it to, the coreutils binary rpm I produce only ever requires libpthread and only test-tls and test-lock switch between requiring libpthread and libpth depending on the setting. In that case I'm happy to build the package to use libpth. In any case, test-lock et al seem to me to be testing gnulib rather than coreutils, although happy to be corrected on that. On the other hand, rpm reports that 492 packages installed on my system require libpthread.so.0. Frequency of use of applications and libraries from those packages may vary from every day (X.org, kdelibs et al) to very rarely (efax-gtk), but none of them hang in the way that this test application does. If you want to try and track this down, I'm more than happy to help, but equally, I'm cool about it if you have better things to do with your time. One day I'm going to have to bite the bullet and upgrade to a more modern distro :-) Thanks again, Chris Interestingly, I've just run test-lock under gdb a few times and it always ran successfully. I'm not really that well qualified to have a stab like this, but that fact does make me wonder whether we have a race/timing problem here. I'll do a bit more hacking on the test-lock program and see if I can get any more diagnostics. Thanks for your help so far. Chris -- The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller
bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib version
On Friday 28 May 2010, Jim Meyering wrote: Chris Clayton wrote: Hi Jim, I've done some more testing and the outcome is reported below. ... [I've reformatted this paragraph for you -- wrapping to 100 columns makes it render in a relatively hard-to-read manner on my 80-col window] Sorry, I've reconfigured kmail to wrap at column 80. If I add --enable-threads=pth to the call to configure, test-lock runs successfuly ever time. If I make it --enable-threads=posix (or let it default to posix), test-lock will very occasionally succeed, but more often than not hangs as per my report above. If I define ENABLE_DEBUGGING as 1 in test-lock.c, test-lock succeeds regardless of Thanks for the details. the threading library that's used. I guess this all points to something like a thread sync problem in libpthread at glibc-2.7. However, it appears that the --enable-threads=blah setting only affects the test applications. Whatever I set it to, the coreutils binary rpm I produce only ever requires libpthread and only test-tls and test-lock switch between requiring libpthread and libpth depending on the setting. In that case I'm happy to build the package to use libpth. In any case, test-lock et al seem to me to be testing gnulib rather than coreutils, although happy to be corrected on that. That's right. The tests under coreutils' gnulib-tests/ directory are unit tests of the gnulib modules used by coreutils. However, as you would expect of thorough unit tests, in many cases they test functionality that is seldom (or never) used in the parent package. So if getting a working coreutils-8.5 package is all you want right now, you're probably safe. Because my glibc is so old, I'm fine with that, but if the gnulib folks want to follow it up, I'm more than happy to help. -- The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller
bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib version
Resend because the first try somehow ended up at the Debbugs-submit
mailing list!
Fingers crossed.
-- Forwarded message --
From: Chris Clayton chris2...@googlemail.com
Date: 27 May 2010 09:19
Subject: Possible bug in coreutils-8.5 or associated gnulib version
To: bug-coreutils@gnu.org
Hi,
I've just tried to build coreutils-8.5. The compilation finished OK,
but make check hangs when
gnulib-tests/test-lock is run. The log showed that the hang occurred
somewhere after the
message Starting test_rwlock was output, so I've added some
additional debugging output to the
test_rwlock function so that it now looks like:
static void
test_rwlock (void)
{
int i;
gl_thread_t checkerthreads[THREAD_COUNT];
gl_thread_t threads[THREAD_COUNT];
/* Initialization. */
for (i = 0; i ACCOUNT_COUNT; i++)
account[i] = 1000;
rwlock_checker_done = 0;
/* Spawn the threads. */
printf (\nCreating %d rwlock_checker_threads:, THREAD_COUNT);
for (i = 0; i THREAD_COUNT; i++)
checkerthreads[i] = gl_thread_create (rwlock_checker_thread, NULL);
printf (OK\n);
printf (Creating %d rwlock_mutator_threads:, THREAD_COUNT);
for (i = 0; i THREAD_COUNT; i++)
threads[i] = gl_thread_create (rwlock_mutator_thread, NULL);
printf (OK\n);
/* Wait for the threads to terminate. */
printf (Waiting for rwlock_mutator_threads to terminate:\n);
for (i = 0; i THREAD_COUNT; i++) {
printf (\t%d\n, i);
gl_thread_join (threads[i], NULL);
}
rwlock_checker_done = 1;
printf (Waiting for rwlock_checker_threads to terminate:\n);
for (i = 0; i THREAD_COUNT; i++) {
printf (\t%d\n, i);
gl_thread_join (checkerthreads[i], NULL);
}
check_accounts ();
}
I compiled the amended test app and ran it a few times. The output I
got is as follows:
[root:/home/chris/rpm/build/coreutils-8.5/gnulib-tests]$ ./test-lock
Starting test_lock ... OK
Starting test_rwlock ...
Creating 10 rwlock_checker_threads:OK
Creating 10 rwlock_mutator_threads:OK
Waiting for rwlock_mutator_threads to terminate:
0
1
^C
[root:/home/chris/rpm/build/coreutils-8.5/gnulib-tests]$ ./test-lock
Starting test_lock ... OK
Starting test_rwlock ...
Creating 10 rwlock_checker_threads:OK
Creating 10 rwlock_mutator_threads:OK
Waiting for rwlock_mutator_threads to terminate:
0
1
^C
[root:/home/chris/rpm/build/coreutils-8.5/gnulib-tests]$ time ./test-lock
Starting test_lock ... OK
Starting test_rwlock ...
Creating 10 rwlock_checker_threads:OK
Creating 10 rwlock_mutator_threads:OK
Waiting for rwlock_mutator_threads to terminate:
0
1
^C
real 23m14.207s
user 0m3.039s
sys 0m4.329s
The final run shows that even if I leave the app to run for several
minutes, it still fails to
complete.
I am running kernel 2.6.34 and my gcc is gcc (GCC) 4.4.5 20100525
(prerelease) (this week's 4.4
snapshot), although I get the same hang if I build and test with gcc-3.4.6.
I'm not subscribed, so please cc me into any reply More than happy to
provide any other information
you need to solve this.
Thanks,
Chris Clayton
--
The more I see, the more I know. The more I know, the less I
understand. Changing Man - Paul Weller
--
The more I see, the more I know. The more I know, the less I
understand. Changing Man - Paul Weller
bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib version
On Thursday 27 May 2010, Jim Meyering wrote: Chris Clayton wrote: I've just tried to build coreutils-8.5. The compilation finished OK, but make check hangs when gnulib-tests/test-lock is run. The log showed that the hang occurred somewhere after the message Starting test_rwlock was output, so I've added some additional debugging output to the test_rwlock function so that it now looks like: ... The final run shows that even if I leave the app to run for several minutes, it still fails to complete. I am running kernel 2.6.34 and my gcc is gcc (GCC) 4.4.5 20100525 (prerelease) (this week's 4.4 snapshot), although I get the same hang if I build and test with gcc-3.4.6. I'm not subscribed, so please cc me into any reply More than happy to provide any other information you need to solve this. Thanks for the report. Thanks for the reply. I cannot reproduce a problem with 2.6.34 and gcc-4.4.4. Is there anything else about your environment that might be unusual? The only thing I can think of is that glibc is a bit old at 2.7, but if I update to a later version, some of my apps stop working [e.g. midnight commander (mc)] and no matter how much recompiling I do, I can't get them to work again. The system started out (5 or 6 years ago) as Peanut Linux, which was a Slackware derivative amended to use rpm for package management. Nowadays, however, many, many packages have been added (KDE,OpenOffice, udev, cherokee - I could go on and on here) and upgraded. But it's finely tuned to the things I do with my computer. I tend to update packages as new versions become available, other than where I bump into dependency clashes or massive rebuild of packages. Can you reproduce that using the latest from git? If you're up to it, here's the build-from-git procedure: http://git.sv.gnu.org/cgit/coreutils.git/tree/README-hacking Had to build and install a few dependencies, but I've done the build-from-git thing and I get the same hang. The call to configure during the build is as follows: ./configure --prefix=/usr --disable-nls --mandir=/usr/man --infodir=/usr/info --disable-acl --disable-rpath --disable-xattr Interestingly, I've just run test-lock under gdb a few times and it always ran successfully. I'm not really that well qualified to have a stab like this, but that fact does make me wonder whether we have a race/timing problem here. I'll do a bit more hacking on the test-lock program and see if I can get any more diagnostics. Thanks for your help so far. Chris -- The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller
Re: Build error with coreutils-8.3
2010/1/10 Jim Meyering j...@meyering.net: Jim Meyering wrote: 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 issue with =glibc-2.9. at least, i have reports that glibc-2.11 works. Right. I think that without the fix below from glibc (glibc-2.9-46-g0f2ae55), the double-inclusion code in gnulib's lib/wchar.in.h doesn't work properly, with the result that /usr/include/wchar.h is never included. commit 0f2ae55cf707947688bd28b55899a148fd3d7646 Author: Ulrich Drepper drep...@redhat.com Date: Mon Dec 29 23:01:38 2008 + [BZ #9694] * wcsmbs/wchar.h: Move undefs for local __need_* constants to the very end. diff --git a/ChangeLog b/ChangeLog index 7696705..333c502 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,9 @@ 2008-12-29 Ulrich Drepper drep...@redhat.com + [BZ #9694] + * wcsmbs/wchar.h: Move undefs for local __need_* constants to the + very end. + * nscd/nscd_gethst_r.c (nscd_gethst_r): Don't use nscd if LOCALDOMAIN is defined. * nscd/nscd_getai.c (__nscd_getai): Likewise. diff --git a/wcsmbs/wchar.h b/wcsmbs/wchar.h index 0fd9e35..aaf278d 100644 --- a/wcsmbs/wchar.h +++ b/wcsmbs/wchar.h @@ -1,4 +1,4 @@ -/* Copyright (C) 1995-2004,2005,2006,2007 Free Software Foundation, Inc. +/* Copyright (C) 1995-2004,2005,2006,2007, 2008 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -839,9 +839,9 @@ __END_DECLS #endif /* _WCHAR_H defined */ +#endif /* wchar.h */ + /* Undefined all __need_* constants in case we are included to get those constants but the whole file was already read. */ #undef __need_mbstate_t #undef __need_wint_t - -#endif /* wchar.h */ I think it's a combination of the above and the recent change that added this #ifndef: /* Tru64 with Desktop Toolkit C has a bug: stdio.h must be included before wchar.h. BSD/OS 4.0.1 has a bug: stddef.h, stdio.h and time.h must be included before wchar.h. But avoid namespace pollution on glibc systems. */ #ifndef __GLIBC__ # include stddef.h # include stdio.h # include time.h #endif Removing that #ifndef avoids the failure, as well as including time.h unconditionally, as done in the patch below. I don't have the cpp expansion of exclude.c in front of me now, but I'm pretty sure I saw in it an inclusion of wchar.h via time.h. The combination of that and the glibc bug fixed above seems to be the likely cause. This patch does work, but seems too kludgey for my taste, and it doesn't explain that time.h is required to work around the glibc-2.7..2.9 problem in wchar.h. Yes, I can confirm that applying the patch below allows the build to complete here. I should also note that the build completes _without_ any changes to /usr/include/wchar.h - i.e. _without_ the patch from glibc-2.9 that Jim identified. Feel free to let me know if you would like me to test a less kludgey solution :-) Thanks Chris diff --git a/lib/wchar.in.h b/lib/wchar.in.h index c0323fe..7766b2f 100644 --- a/lib/wchar.in.h +++ b/lib/wchar.in.h @@ -60,8 +60,8 @@ #ifndef __GLIBC__ # include stddef.h # include stdio.h -# include time.h #endif +#include time.h /* Include the original wchar.h if it exists. Some builds of uClibc lack it. */ -- No, Sir; there is nothing which has yet been contrived by man, by which so much happiness is produced as by a good tavern or inn - Doctor Samuel Johnson
Re: Build error with coreutils-8.3
2010/1/10 Bruno Haible br...@clisp.org: This patch works too (by doing the right thing when wchar.h is being included from within /usr/include/wctype.h), and seems to be the right thing, therefore I'm applying it. This patch allows the build to complete too. Thanks. Chris 2010-01-10 Bruno Haible br...@clisp.org wchar: Fix compilation error when wchar.h is used from coreutils. * lib/wchar.in.h: Treat __need_wint_t like __need_mbstate_t. Reported by Brian Gough b...@gnu.org and Chris Clayton chris2...@googlemail.com via Mike Frysinger vap...@gentoo.org and Jim Meyering j...@meyering.net. --- lib/wchar.in.h.orig Sun Jan 10 12:49:55 2010 +++ lib/wchar.in.h Sun Jan 10 12:49:16 2010 @@ -30,9 +30,9 @@ �...@pragma_system_header@ #endif -#if defined __need_mbstate_t || (defined __hpux ((defined _INTTYPES_INCLUDED !defined strtoimax) || defined _GL_JUST_INCLUDE_SYSTEM_WCHAR_H)) || defined _GL_ALREADY_INCLUDING_WCHAR_H +#if defined __need_mbstate_t || defined __need_wint_t || (defined __hpux ((defined _INTTYPES_INCLUDED !defined strtoimax) || defined _GL_JUST_INCLUDE_SYSTEM_WCHAR_H)) || defined _GL_ALREADY_INCLUDING_WCHAR_H /* Special invocation convention: - - Inside uClibc header files. + - Inside glibc and uClibc header files. - On HP-UX 11.00 we have a sequence of nested includes wchar.h - stdlib.h - stdint.h, and the latter includes wchar.h, once indirectly stdint.h - sys/types.h - inttypes.h - wchar.h -- No, Sir; there is nothing which has yet been contrived by man, by which so much happiness is produced as by a good tavern or inn - Doctor Samuel Johnson
Build error with coreutils-8.3
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: In function 'mb_width_aux': mbchar.h:241: warning: implicit declaration of function 'wcwidth' In file included from exclude.c:38: mbuiter.h: At top level: mbuiter.h:112: error: expected specifier-qualifier-list before 'mbstate_t' mbuiter.h: In function 'mbuiter_multi_next': mbuiter.h:126: error: 'struct mbuiter_multi' has no member named 'next_done' mbuiter.h:131: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:136: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:137: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:137: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:138: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:142: warning: implicit declaration of function 'mbsinit' mbuiter.h:142: error: 'struct mbuiter_multi' has no member named 'state' mbuiter.h:145: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:145: warning: implicit declaration of function 'mbrtowc' mbuiter.h:145: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:145: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:146: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:147: error: 'struct mbuiter_multi' has no member named 'state' mbuiter.h:148: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:151: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:152: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:156: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:159: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:159: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:160: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:166: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:169: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:170: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:171: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:173: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:177: error: 'struct mbuiter_multi' has no member named 'state' mbuiter.h:181: error: 'struct mbuiter_multi' has no member named 'next_done' mbuiter.h: In function 'mbuiter_multi_reloc': mbuiter.h:187: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h: In function 'mbuiter_multi_copy': mbuiter.h:194: error: 'struct mbuiter_multi' has no member named 'state' mbuiter.h:194: error: 'const struct mbuiter_multi' has no member named 'state' mbuiter.h:194: error: 'mbstate_t' undeclared (first use in this function) mbuiter.h:194: error: (Each undeclared identifier is reported only once mbuiter.h:194: error: for each function it appears in.) mbuiter.h:196: error: 'struct mbuiter_multi' has no member named 'state' mbuiter.h:197: error: 'struct mbuiter_multi' has no member named 'next_done' mbuiter.h:197: error: 'const struct mbuiter_multi' has no member named 'next_done' mbuiter.h:198: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:198: error: 'const struct mbuiter_multi' has no member named 'cur' exclude.c: In function 'string_hasher_ci': exclude.c:161: error: 'mbui_iterator_t' has no member named 'cur' exclude.c:161: error: 'mbui_iterator_t' has no member named 'state' exclude.c:161: error: 'mbstate_t' undeclared (first use in this function) exclude.c:161: error: 'mbui_iterator_t' has no member named 'next_done' exclude.c:161: error: 'mbui_iterator_t' has no member named 'cur' exclude.c:161: error: 'mbui_iterator_t' has no member named 'cur' exclude.c:161: error: 'mbui_iterator_t' has no member named 'cur' exclude.c:161: error: 'mbui_iterator_t' has no member named 'cur' exclude.c:161:
Fwd: 'make check' failure with coreutils-8.2
Added bug-coreutils@gnu.org, which I missed on the reply below... -- Forwarded message -- From: Chris Clayton chris2...@googlemail.com Date: 2009/12/12 Subject: Re: 'make check' failure with coreutils-8.2 To: Jim Meyering j...@meyering.net 2009/12/12 Jim Meyering j...@meyering.net: Chris Clayton wrote: I've just built coreutils-8.2 and make check fails and asks for a report to this mail address. configure is run thusly: ./configure --prefix=/usr --disable-acl --disable-rpath --disable-nls --disable-xattr ... Thanks for the report. What type of system are you using? (uname -a) It's a linux system running 2.6.32. Somehow, the kernel was set up to build without inotify support for userland. My 2.6.31 kernel has inotify support, so I've no idea how it got switched off. That failure means that your system's kernel lacks inotify support and that test failed to account for the possibility. Can you confirm that the patch below solves the problem? Yes, the patch allows the coreutils build to complete with the inotify-less kernel. I've rebuilt and installed my kernel too :-) Thanks Jim. Chris -- No, Sir; there is nothing which has yet been contrived by man, by which so much happiness is produced as by a good tavern or inn - Doctor Samuel Johnson -- No, Sir; there is nothing which has yet been contrived by man, by which so much happiness is produced as by a good tavern or inn - Doctor Samuel Johnson
