Fix for warning issue in libtool
Reference: http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html Re: automake 1.12 and AM_PROG_AR From: Nick Bowler Subject: Re: automake 1.12 and AM_PROG_AR Date: Thu, 10 May 2012 17:16:04 -0400 User-agent: Mutt/1.5.21 (2010-09-15) On 2012-05-10 12:52 +0200, Simon Josefsson wrote: > Hi, > > I have received patches similar to the one below for several of my > projects already, and I'm beginning to think there may be something that > could be improved in automake. Why does automake 1.12 need something > that 1.11 doesn't even recognize? Perhaps a smoother way to introduce > this behaviour is to let 1.12 automatically enable it? > > Alternatively, is there some other way to address the warnings that is > better? Does it indicate a real problem in my projects? > > http://lists.gnu.org/archive/html/help-libidn/2012-05/msg00000.html > http://lists.gnu.org/archive/html/help-libidn/2012-05/txtqAGOGgtPqj.txt FYI, since the patch is so short it would have been helpful to include it inline in your email. I've taken the liberty of reproducing it below: > --- libidn-1.24.orig/configure.ac > +++ libidn-1.24/configure.ac > @@ -34,6 +34,10 @@ AC_SUBST(LT_CURRENT, 17) > AC_SUBST(LT_REVISION, 7) > AC_SUBST(LT_AGE, 6) > > +# automake 1.12 seems to require this, but automake 1.11 doesn't recognize it > +m4_pattern_allow([AM_PROG_AR]) > +AM_PROG_AR > + > AC_PROG_CC > gl_EARLY > lgl_EARLY First off, this patch seems wrong at a first glance by its use of m4_pattern_allow: this is saying that "It's ok for AM_PROG_AR to appear verbatim in the configure script". This suggests to me that the patch didn't actually get tested (well) on Automake 1.11, since there will almost certainly be an error about AM_PROG_AR at configure time. This one should actually work properly on both old and new Automake (untested): m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) That being said, the new warning is enabled by the -Wextra-portability option that was added to Automake-1.12. I'm by no means an export on this issue, but I think it relates to new support for building with the Microsoft compiler: in other words, I think that ignoring this warning will not cause regressions in your package but, instead, your package will simply not be able to make use of the new feature. Regardless, I believe that for most packages the new warning is actually caused by Libtool, and therefore the correct place to add the call to AM_PROG_AR is in libtool itself, rather than ad-hoc patching of each package individually. You can silence the warnings (but not fix them) by adding -Wno-extra-portability to AM_INIT_AUTOMAKE. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) (cherry picked from commit 350999187285300b1b7dec574cc745617e239bec)
This commit is contained in:
parent
2bb79879b7
commit
fb04f12a8a
@ -518,6 +518,7 @@ AC_MSG_RESULT($docdir)
|
||||
#
|
||||
AC_PROG_CC
|
||||
AM_PROG_CC_C_O
|
||||
m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
|
||||
AC_PROG_LIBTOOL
|
||||
AC_PROG_INSTALL
|
||||
AC_PROG_MAKE_SET
|
||||
|
Loading…
x
Reference in New Issue
Block a user