libtool
[Top][All Lists]
Advanced

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

Re: [RFC] simple sanity checking libtool versions at runtime


From: Ralf Wildenhues
Subject: Re: [RFC] simple sanity checking libtool versions at runtime
Date: Mon, 12 Dec 2005 15:43:42 +0100
User-agent: Mutt/1.5.11

Hi Mike,

* Mike Frysinger wrote on Sun, Dec 11, 2005 at 07:30:45PM CET:
> since Gentoo is a from-source distribution, we do a lot of compiling ...
> as such, our maintainers often have to fix bugs in autotool source files
> in misc packages (bugs in say configure.ac, not bugs in autoconf).  thus
> it is not uncommon that we re-run portions of autotools so that we dont
> have huge patches against generated files (like configure or
> Makefile.in).

Sure.  Good idea.

> since autotools can be a bit on the confusing side for people who are
> not familiar with them, we hit many cases of package maintainers
> regenerating some autotool files, but not all of them.  so we would 
> hit cases where the libtool code in configure was from a diff version
> of libtool than the ltmain.sh file.  the end result was that we would
> see weird packing issues were say shared libraries were being created
> without a '.so' extension.

Ah, ok.

> our solution was to patch libtool in Gentoo with a sanity check where
> configure would grep the version written in the ltmain.sh file and if
> it did not match the version in configure, the process bail out with
> a fun error message.

Hmm.  In CVS HEAD we have such a sanity check already, in ltmain's
func_check_version_match.  But it bails out only at the time libtool is
run, not during configure.  It's more precise than yours: it checks for
package_revision as well.

> find attached said patch written by Martin Schlemmer and myself (well,
> mostly Martin ;D) against cvs.

Hmm.  I'm uncertain.  There may be a point in erroring out at configure
time already.  Even nicer would be an error at m4 (autoconf) time
already.  I don't believe this is possible though (not sure though).

Note a couple of minor nits with your patch below.  If you still think
it worthwhile for HEAD, I'd probably take an updated version of it.  :)

Cheers, and thank you,
Ralf

> 2005-12-11  Martin Schlemmer  <address@hidden>
> 
>       * libltdl/m4/libtool.m4 (_LT_VERSION_CHECK): sanity check to make
>       sure libtool.m4 version matches ltmain.sh version.
>       (LT_INIT): execute new _LT_VERSION_CHECK function.
> 
> Index: libltdl/m4/libtool.m4
> ===================================================================
> RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
> retrieving revision 1.51
> diff -u -r1.51 libtool.m4
> --- libltdl/m4/libtool.m4     8 Dec 2005 04:17:02 -0000       1.51
> +++ libltdl/m4/libtool.m4     8 Dec 2005 19:41:08 -0000
> @@ -68,6 +68,7 @@
>  AC_REQUIRE([LTVERSION_VERSION])dnl
>  m4_require([_LT_PROG_LTMAIN])dnl
>  m4_require([_LT_SET_OPTIONS], [_LT_SET_OPTIONS([$1])])dnl
> +AC_REQUIRE([_LT_VERSION_CHECK])dnl
>  
>  # This can be used to rebuild libtool when needed
>  LIBTOOL_DEPS="$ltmain"
> @@ -115,6 +116,34 @@
>  : ${MV="mv -f"}
>  : ${RM="rm -f"}
>  ])# _LT_FILEUTILS_DEFAULTS
> +
> +
> +# _LT_VERSION_CHECK
> +# -----------------
> +# Check that we do not have a version mismatch between libtool.m4 and
> +# ltmain.sh.
> +# Note that this should be called after _LT_PROG_LTMAIN have setup $ltmain,
> +# but *before* _LT_SETUP so that libtool is not created.
> +AC_DEFUN([_LT_VERSION_CHECK],

This is an internal macro; so it's ok and consistent to use m4_defun
here and accordingly m4_require([_LT_VERSION_CHECK]) above.

> +[AC_REQUIRE([_LT_PROG_LTMAIN])dnl

You should m4_require instead of AC_REQUIRE, since _LT_PROG_LTMAIN is
m4_defun'ed, not AC_DEFUN'ed.

Also, I believe you should require LTVERSION_VERSION here, since you
use it.  Requirements only induce a partial ordering.

> +AC_BEFORE([$0], [_LT_SETUP])dnl
> +
> +AC_MSG_CHECKING([for correct ltmain.sh version])
> +_ltmain_version=`grep '^[[   ]]*VERSION=' $ltmain | sed -e 's/^[[    
> ]]*VERSION=//'`

No need for the grep here, I think:
  _ltmain_version=`sed -n '/^[[         ]]*VERSION=/{s/^[[      
]]*VERSION=//;p;q;}' "$ltmain"`

> +if test X"${_ltmain_version+set}" != Xset ; then

This condition is always true after the previous line.  I believe you
meant
  ${_ltmain_version:+set}

which is not understood by ancient shells though, but
  if test -z "$_ltmain_version"
is.

> +  AC_MSG_RESULT([no])
> +  AC_MSG_ERROR([could not determine ltmain.sh version])
> +fi
> +
> +_lt_m4_verion=m4_quote(m4_defn([LT_PACKAGE_VERSION]))

I would s/verion/version/

> +if test "X$_lt_m4_verion" = "X$_ltmain_version" ; then

Ditto.

Additionally, I think there may be an issue on w32 with line endings
here (untested).  Maybe a
  tr -d '\015'
after above sed is enough to cure this.

> +  AC_MSG_RESULT([yes])
> +else
> +  AC_MSG_RESULT([no])
> +  AC_MSG_ERROR([ltmain.sh version mismatch
> +Try running 'libtoolize -c -f; aclocal; autoconf' and then try again'])

This does not have to be true: it's entirely possible that aclocal does
not need to be run, or that it needs certain arguments to run correctly,
just as with libtoolize.  Furthermore, automake may need to be run as
well.  Unfortunate but true.

func_check_version_match has better error messages, I believe.

Also please not the ' don't match up (and libtool uses the ` ' weird
looking quotes, as other non-localized GNU software does).

> +fi
> +])# _LT_VERSION_CHECK
>  
>  
>  # _LT_SETUP




reply via email to

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