On Tue, 2003-11-25 at 13:27, Gary V. Vaughan wrote: > Scott James Remnant wrote: > | The gotcha is that for some reason aclocal pulls in both m4/libtool.m4 > | AND /usr/share/aclocal/libtool.m4 into aclocal.m4 and puts the latter > | last, so its macros get used. > > This means that aclocal has found a dependency on a macro that is defined in > /usr/share/aclocal/libtool.m4, but not $top_srcdir/m4/libtool.m4 (m4_defined > macros can't be seen by aclocal.m4). If you have time to investigate, it > would be nice to prevent this happening before we release. > Ok, I've investigated this and I think the problem is that we're assigning too much intelligence to aclocal :-(
As far as I can tell it has two basic phases: 1) Scan every m4 file and build up a list of AC_DEFUNs (or AU_DEFUN) it can find, and remember which file it found them in[0]. 2) Scan configure.{ac,in} looking for the name of any macro it saw a definition for, pull in the appropriate file and then scan that file in the same way (recurse until happy). This means if you use AC_FOO in m4/libtool.m4 then the first file that happens to AC_DEFUN that will get included, even though it's defined with m4_define in that same file. In other words, anything previously defined with AC_DEFUN in older libtool.m4 files will need to be defined with AC_DEFUN in later versions too, including 1.6. Here's the list of m4_define macros that need to be changed back to AC_DEFUN simply because they used to be defined with it[1]: AC_LIBTOOL_CONFIG AC_LIBTOOL_LINKER_OPTION _LT_AC_LANG_C_CONFIG _LT_AC_LANG_GCJ_CONFIG _LT_AC_LANG_RC_CONFIG _LT_AC_PROG_ECHO_BACKSLASH _LT_AC_SHELL_INIT _LT_AC_SYS_LIBPATH_AIX _LT_AC_TAGVAR But that's not enough, oh no, precious. You see, aclocal doesn't know about macros supplied by Autoconf. So if we were to define a macro in an older libtool.m4, say AC_PROG_EGREP, and removed it because it's now included in the version of Autoconf we AC_PREREQ on, aclocal wouldn't know about it so would pull in the older libtool.m4 simply because it defined it. So in summary, to stop this madness, we need to either change the definition of the above macro list from m4_define to AC_DEFUN or rename the macros and then restore the definition of AC_PROG_EGREP even if it's just a hack like this: # AC_PROG_EGREP # ------------- # This is included in Autoconf, but aclocal will pull in an # older libtool.m4 unless we AC_DEFUN it *sigh* m4_ifndef([AC_PROG_EGREP], [AC_DEFUN([AC_PROG_EGREP], [])]) Scott [0] Interestingly, it doesn't consider 'dnl' to be a comment and if you do 'dnl AC_DEFUN([FOO])' it considers that a valid definition of 'FOO'. It does ignore '## AC_DEFUN([FOO])' though, is this m4ly-correct? [1] Or we could cheat and rename them, which is why _LT_AC_TAG_CONFIG (was _LT_AC_TAGCONFIG) isn't in that list. -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool