GNU bug report logs - #8104
automake suggests use of AC_PROG_LIBTOOL, this has been replaced by LT_INIT

Previous Next

Full log

Message #19 received at 8104 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 8104 <at> debbugs.gnu.org, Jack Kelly <jack <at> jackkelly.name>,
	automake-patches <at> gnu.org
Subject: Re: bug#8104: automake suggests use of AC_PROG_LIBTOOL, this has
	been replaced by LT_INIT
Date: Sat, 26 Feb 2011 14:37:45 +0100

* Stefano Lattarini wrote on Sat, Feb 26, 2011 at 02:08:39PM CET:
> BTW, such kind of checks would be much easier to perform with Paolo's
> pending patch for ACLOCAL_PATH support in place; pointer:
>  <http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00089.html>

Hmmyes, we have a lot of old pending stuff unfortunately ...

> On Saturday 26 February 2011, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Thu, Feb 24, 2011 at 10:45:11AM CET:
> > LT_PREREQ has been introduced in 1.9b only.  Also, I
> > think that if the LT_PREREQ check fails, it will fail already
> > at aclocal run time,
> >
> Oops, I dind't think of that.
> 
> > but I am not sure of that.
> >
> Better play safe anyway IMHO.  What about the following squash-in?

Well, not using LT_PREREQ seems like another step back: situations like
this is what LT_PREREQ was designed for.  How about something like this?

  m4_ifdef([LT_PREREQ],
    [LT_PREREQ([2.0])],
    [m4_fatal([Libtool version too old], [63])])

(untested, sorry)

Thanks,
Ralf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.