[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
getting rid of the AC_PROG_EGREP replacement (Was: Re: 4-gary-use-ac256-
getting rid of the AC_PROG_EGREP replacement (Was: Re: 4-gary-use-ac256-compiler-header-checking.patch)
Wed, 27 Aug 2003 23:43:16 +0200
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux)
>>> "Gary" == Gary V Vaughan <address@hidden> writes:
Gary> Alexandre Duret-Lutz wrote:
>> On Thu, Aug 14, 2003 at 05:07:25PM +0100, Gary V. Vaughan wrote:
>> > AC_DEFUN([AC_LIBTOOL_SETUP],
>> > -[AC_PREREQ(2.50)dnl
>> > +[AC_PREREQ(2.56)dnl We use the new compiler based header checking in 2.56
>> Oh yes!
>> That means the EGREP hack can be removed.
Gary> Except that when I remove it, I can no longer bootstrap libtool at all
Gary> Perhaps the AC_REQUIRE machinery is killing m4? (I am
Gary> using m4-1.4 for this btw).
Nope. The issue is twofold.
1 - There is an unquoted call to _LT_AC_TAGVAR in _LT_AC_LANG_C_CONFIG.
Normally it is doesn't choke Autoconf because _LT_AC_TAGVAR is
only defined after this use.
However if libtool.m4 was to be included twice, then
Autoconf would barf on the second occurrence of this
unquoted call, since it would follow the first definition of
As a matter of fact, the warning would look something like
Gary> aclocal.m4:8368: error: m4_defn: undefined macro: _m4_divert_diversion
Gary> aclocal.m4:5798: _LT_AC_TAGVAR is expanded from...
Gary> aclocal.m4:8368: the top level
2 - Once you remove the definition of AC_PROG_EGREP from
libtool.m4, you hit the issue I complained about in the
aforementioned mail. A package that uses AC_PROG_EGREP gets
a full copy of /usr/share/aclocal/libtool.m4 in its
Libtool uses AC_PROG_EGREP and you have an old copy of
libtool.m4 defining AC_PROG_EGREP in your system? then you
get a copy of that in aclocal.m4.
Now that means you have two versions of libtool.m4 in your
aclocal.m4: the local copy and the system's copy. Which
brings us to point 1, and triggers the unquoted call bug.
Isn't this wonderful? Two feet, two bullets, two holes :)
In order to bootstrap the following patch I suggest you first
uninstall Libtool, or at least fix you system's libtool.m4
similarly. Another possibility (which I haven't tried) would be
to first apply only the _LT_AC_TAGVAR chunk, bootstrap and
install that, and then apply the rest of the patch.
I realize it will be the hell for people who "cvs update", and I
can't think of any solution.
I guess the moral is that one should never try to supply a
replacement macro for an Autoconf macro. Instead one should
write a custom MY_PROG_EGREP wrapper and use it.
2003-08-27 Alexandre Duret-Lutz <address@hidden>
* libtool.m4 (_LT_AC_LANG_C_CONFIG): Fix unquoted call to
(AC_PROG_EGREP): Remove, now that Libtool requires Autoconf 2.56.
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.333
diff -u -r1.333 libtool.m4
--- libtool.m4 27 Aug 2003 16:24:44 -0000 1.333
+++ libtool.m4 27 Aug 2003 20:58:08 -0000
@@ -1856,21 +1856,6 @@
-# This is predefined starting with Autoconf 2.54, so this conditional
-# definition can be removed once we require Autoconf 2.54 or later.
-[AC_CACHE_CHECK([for egrep], [ac_cv_prog_egrep],
- [if echo a | (grep -E '(a|b)') >/dev/null 2>&1
- then ac_cv_prog_egrep='grep -E'
- else ac_cv_prog_egrep='egrep'
# find a file program which can recognise shared library
@@ -2504,7 +2489,7 @@
if test -n "$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)"; then
AC_MSG_WARN([`$CC' requires `$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)' to build
- if echo "$old_CC $old_CFLAGS " | grep "[[
]]$]_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)[[[ ]]" >/dev/null; then :
+ if echo "$old_CC $old_CFLAGS " | grep "[[
]]$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)[[ ]]" >/dev/null; then :
AC_MSG_WARN([add `$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)' to the CC or
CFLAGS env variable and reconfigure])