[PATCH] maint.mk: also prohibit #undef of always-defined symbols
I noticed some #undef uses that were made obsolete by gnulib use,
so tweaked this syntax-check rule to spot them, just like it does
for #define'd symbols:
From 8b4add2c64d10b260c21352768e22d41dc9d2ff7 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Thu, 27 May 2010 13:33:04 +0200
Subject: [PATCH] maint.mk: also prohibit #undef of always-defined symbols
* top/maint.mk (def_sym_regex): Handle #undef as well as #define.
Allow more than one space before the symbol name.
(sc_prohibit_always-defined_macros): Use grep's -E, now that
the regexp uses alternation.
---
ChangeLog|8
top/maint.mk |5 +++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 1ee9575..6a54e63 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2010-05-27 Jim Meyering meyer...@redhat.com
+
+ maint.mk: also prohibit #undef of always-defined symbols
+ * top/maint.mk (def_sym_regex): Handle #undef as well as #define.
+ Allow more than one space before the symbol name.
+ (sc_prohibit_always-defined_macros): Use grep's -E, now that
+ the regexp uses alternation.
+
2010-05-26 Eric Blake ebl...@redhat.com
maint.mk: avoid echo -e
diff --git a/top/maint.mk b/top/maint.mk
index 045537f..644fbb6 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -689,7 +689,8 @@ define def_sym_regex
perl -lne '$(gl_extract_significant_defines_)' $$f; \
done; \
) | sort -u \
- | sed 's/^/^ *# *define /;s/$$/\\/'
+ | grep -Ev '^ATTRIBUTE_NORETURN' \
+ | sed 's/^/^ *# *(define|undef) */;s/$$/\\/'
endef
# Don't define macros that we already get from gnulib header files.
@@ -698,7 +699,7 @@ sc_prohibit_always-defined_macros:
case $$(echo all: | grep -l -f - Makefile) in Makefile);; *) \
echo '$(ME): skipping $@: you lack GNU grep' 12; exit 0;; \
esac; \
- $(def_sym_regex) | grep -f - $$($(VC_LIST_EXCEPT))\
+ $(def_sym_regex) | grep -E -f - $$($(VC_LIST_EXCEPT)) \
{ echo '$(ME): define the above via some gnulib .h file' \
12; exit 1; } || :;\
fi
--
1.7.1.348.gb26ba
test-vc-list-files-cvs.sh failure on OS X 10.6.3
While checking for regressions in very old m4 patches I hadn't gotten round to submitting, I notice that the HEAD revision of both branch-1.4 and branch-1.6 fail this test: ; cd Devo/m4--release--1.4 ; git pull ./bootstrap mkdir +build cd +build ../configure make all check [[...]] PASS: test-vc-list-files-git.sh FAIL: test-vc-list-files-cvs.sh PASS: test-version-etc.sh PASS: test-wchar PASS: test-wcrtomb.sh PASS: test-wctype PASS: test-xalloc-die.sh PASS: test-xmemdup0 PASS: test-xvasprintf === 1 of 115 tests failed See tests/test-suite.log Please report to bug...@gnu.org === [[...]] ; cat tests/test-suite.log GNU M4 1.4.14.1-a90f: tests/test-suite.log 1 of 102 tests failed. (1 test was not run). .. contents:: :depth: 2 SKIP: test-c-stack2.sh (exit: 77) = cannot tell stack overflow from crash; consider installing libsigsegv FAIL: test-vc-list-files-cvs.sh (exit: 1) = find: illegal option -- - ind: illegal option -- - ind: illegal option -- t ind: illegal option -- y ind: illegal option -- p ind: illegal option -- e ind: illegal option -- = ind: illegal option -- A ind: illegal option -- F ind: illegal option -- G ind: illegal option -- M find: ind: No such file or directory --- expected2010-05-28 11:36:21.0 +0700 +++ actual 2010-05-28 11:36:21.0 +0700 @@ -1,3 +1,3 @@ -b -c -d/a +.: +? actual +? expected Obviously, the test is assuming GNU find (which is called gfind on my machine, but it doesn't come with Mac OS, which ships only BSD find), but with a cursory look around I couldn't see where the failing find was invoked. With gfind in my PATH, I also tried rerunning the testsuite with: ; FIND=gfind make check ...but I get the same failure. Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib version
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, Using glibc-2.7 with a new kernel is unusual indeed. Definitely suspect. I've Cc'd bug-gnulib, since it's clearly involved. 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
