[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 84-gary-diagnose-version-mismatch.patch

From: Scott James Remnant
Subject: Re: 84-gary-diagnose-version-mismatch.patch
Date: Sun, 14 Mar 2004 17:39:05 +0000

On Fri, 2004-02-20 at 19:08, Gary V. Vaughan wrote:

Something I didn't catch last time...

>       Sweeping changes to the user interface to libtool from
>       `' to be more like AC_INIT and accept a space
>       delimited list of options.  Instead of calling `AC_LIBTOOL_DLOPEN;
>       AC_PROG_LIBTOOL', we now recommend `LT_INIT([dlopen])':
>       * m4/libtool.m4 (AC_PROG_LIBTOOL, _AC_PROG_LIBTOOL)
>       (AC_LIBTOOL_SETUP): Removed.  Added AU_DEFUNs.
>       (LT_INIT): Replace with an Autoconf like interface which accepts a
>       version number as a minimum required libtool release at configure
>       time.
>       * m4/lt~obsolete.m4 (AC_LIBTOOL_SETUP, _AC_PROG_LIBTOOL)
>       (_LT_PROG_LTMAIN):  More AC_DEFUNs that have been retracted.
There's no need to add _AC_PROG_LIBTOOL to lt~obsolete.m4.

We only need to add to this file where a macro that was AC_DEFUN has
been moved to m4_define (or some other equivalent) and is *still*
referenced in the m4 files.

descent m4% grep _AC_PROG_LIBTOOL *.m4
descent m4%

There aren't any references left, so aclocal won't stupidly pull in an
old libtool.m4, which is what lt~obsolete.m4 is designed to prevent.

All the other macros in there are still referenced, so need to be there.

Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]