Re: Version mismatch error
Hello Sergio, * Sergio Belkin wrote on Mon, Oct 18, 2010 at 06:33:17PM CEST: > I have project with autotools made on Ubuntu, but when I want to > compile on CentOS it ends with error: > > libtool: Version mismatch error. This is libtool 2.2.6b > Debian-2.2.6b-2ubuntu1, but the > libtool: definition of this LT_INIT comes from libtool 2.2.10. > libtool: You should recreate aclocal.m4 with macros from libtool > 2.2.6b Debian-2.2.6b-2ubuntu1 > libtool: and run autoconf again. > > I was using 2.2.10 (compiled) on CentOS. Is there not compatibility > between 2.2.x releases. Is there not a way to make it works with any > libtool 2.2.x? The 2.2.x releases are all compatible in the sense that the command-line API between them is upward-compatible. However, the version from which the libtool.m4 and ltversion.m4 (and a couple more files) macros are taken, and the file ltmain.sh is from, must be exactly identical. The API between ltmain and the macros is mostly an internal detail and not guaranteed to remain stable between releases. So if you re-libtoolize, copying in a new ltmain.sh, you need to also ensure that the new macros are used. Depending on your package setup, that means either passing --install to libtoolize (when AC_CONFIG_MACRO_DIR has been set in configure.ac), or running aclocal with flags set so that it finds the right Libtool macros (either by some -I include-path, or setting the path in the dirlist file of the aclocal installation), or possibly hand-copying macro files or file contents to your aclocal.m4 file. Details are documented in the manual. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Version mismatch error
2010/10/20 Ralf Wildenhues : > Hello Sergio, > > * Sergio Belkin wrote on Mon, Oct 18, 2010 at 06:33:17PM CEST: >> I have project with autotools made on Ubuntu, but when I want to >> compile on CentOS it ends with error: >> >> libtool: Version mismatch error. This is libtool 2.2.6b >> Debian-2.2.6b-2ubuntu1, but the >> libtool: definition of this LT_INIT comes from libtool 2.2.10. >> libtool: You should recreate aclocal.m4 with macros from libtool >> 2.2.6b Debian-2.2.6b-2ubuntu1 >> libtool: and run autoconf again. >> >> I was using 2.2.10 (compiled) on CentOS. Is there not compatibility >> between 2.2.x releases. Is there not a way to make it works with any >> libtool 2.2.x? > > The 2.2.x releases are all compatible in the sense that the command-line > API between them is upward-compatible. However, the version from which > the libtool.m4 and ltversion.m4 (and a couple more files) macros are > taken, and the file ltmain.sh is from, must be exactly identical. The > API between ltmain and the macros is mostly an internal detail and not > guaranteed to remain stable between releases. So if you re-libtoolize, > copying in a new ltmain.sh, you need to also ensure that the new macros > are used. > > Depending on your package setup, that means either passing --install to > libtoolize (when AC_CONFIG_MACRO_DIR has been set in configure.ac), or > running aclocal with flags set so that it finds the right Libtool macros > (either by some -I include-path, or setting the path in the dirlist file > of the aclocal installation), or possibly hand-copying macro files or > file contents to your aclocal.m4 file. Details are documented in the > manual. > > Hope that helps. > > Cheers, > Ralf > After a lot of usage and thinking over it, yes it does ;) -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com Sergio Belkin - ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Version mismatch error
On Wed, Oct 20, 2010 at 10:49 AM, Ralf Wildenhues wrote: > Hello Sergio, > > * Sergio Belkin wrote on Mon, Oct 18, 2010 at 06:33:17PM CEST: >> I have project with autotools made on Ubuntu, but when I want to >> compile on CentOS it ends with error: >> >> libtool: Version mismatch error. This is libtool 2.2.6b >> Debian-2.2.6b-2ubuntu1, but the >> libtool: definition of this LT_INIT comes from libtool 2.2.10. >> libtool: You should recreate aclocal.m4 with macros from libtool >> 2.2.6b Debian-2.2.6b-2ubuntu1 >> libtool: and run autoconf again. >> >> I was using 2.2.10 (compiled) on CentOS. Is there not compatibility >> between 2.2.x releases. Is there not a way to make it works with any >> libtool 2.2.x? > > The 2.2.x releases are all compatible in the sense that the command-line > API between them is upward-compatible. However, the version from which > the libtool.m4 and ltversion.m4 (and a couple more files) macros are > taken, and the file ltmain.sh is from, must be exactly identical. The > API between ltmain and the macros is mostly an internal detail and not > guaranteed to remain stable between releases. So if you re-libtoolize, > copying in a new ltmain.sh, you need to also ensure that the new macros > are used. > > Depending on your package setup, that means either passing --install to > libtoolize (when AC_CONFIG_MACRO_DIR has been set in configure.ac), or > running aclocal with flags set so that it finds the right Libtool macros > (either by some -I include-path, or setting the path in the dirlist file > of the aclocal installation), or possibly hand-copying macro files or > file contents to your aclocal.m4 file. Details are documented in the > manual. Hi Ralf, It would nice if libtoolize when run without --install (e.g. when run by autoreconf without --install) would detect that ltmain.sh and libtool.m4 are out of sync and error. One of the most common autotools errors I see is that people run bare autoreconf and things break strangely (to them) some time later. What do you think? -- Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Version mismatch error
Hello Dan, * Dan Nicholson wrote on Fri, Dec 03, 2010 at 02:43:04PM CET: > On Wed, Oct 20, 2010 at 10:49 AM, Ralf Wildenhues wrote: > > Depending on your package setup, that means either passing --install to > > libtoolize (when AC_CONFIG_MACRO_DIR has been set in configure.ac), or > > running aclocal with flags set so that it finds the right Libtool macros > > (either by some -I include-path, or setting the path in the dirlist file > > of the aclocal installation), or possibly hand-copying macro files or > > file contents to your aclocal.m4 file. Details are documented in the > > manual. > It would nice if libtoolize when run without --install (e.g. when run > by autoreconf without --install) would detect that ltmain.sh and > libtool.m4 are out of sync and error. One of the most common autotools > errors I see is that people run bare autoreconf and things break > strangely (to them) some time later. What do you think? If we can do a warning or error reliably, then I'm all for it. I don't think it can be done in libtoolize though, because aclocal may be called afterwards and fix things up. autoreconf might call libtoolize with some special --check argument or so, to tell it that aclocal --install won't be called afterwards. Putting the warning into automake seems possible but an ugly hack. We could put a check into autoreconf, but then non-autoreconf users wouldn't get the extra safety. It's not easy. :-/ Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Version mismatch error
On Fri, Dec 3, 2010 at 7:38 AM, Ralf Wildenhues wrote: > Hello Dan, > > * Dan Nicholson wrote on Fri, Dec 03, 2010 at 02:43:04PM CET: >> On Wed, Oct 20, 2010 at 10:49 AM, Ralf Wildenhues wrote: >> > Depending on your package setup, that means either passing --install to >> > libtoolize (when AC_CONFIG_MACRO_DIR has been set in configure.ac), or >> > running aclocal with flags set so that it finds the right Libtool macros >> > (either by some -I include-path, or setting the path in the dirlist file >> > of the aclocal installation), or possibly hand-copying macro files or >> > file contents to your aclocal.m4 file. Details are documented in the >> > manual. > >> It would nice if libtoolize when run without --install (e.g. when run >> by autoreconf without --install) would detect that ltmain.sh and >> libtool.m4 are out of sync and error. One of the most common autotools >> errors I see is that people run bare autoreconf and things break >> strangely (to them) some time later. What do you think? > > If we can do a warning or error reliably, then I'm all for it. > I don't think it can be done in libtoolize though, because aclocal may > be called afterwards and fix things up. Oh, that's true. > autoreconf might call > libtoolize with some special --check argument or so, to tell it that > aclocal --install won't be called afterwards. Putting the warning into > automake seems possible but an ugly hack. We could put a check into > autoreconf, but then non-autoreconf users wouldn't get the extra safety. The last time I thought about this, I wanted to have autoreconf call libtoolize with --check if available. I got stuck on the libtoolize part of the patch because I didn't know the right way to add the serial number checks. If you could add a --check in libtoolize that just sanity checks the setup, then I'd be happy to send a patch for autoreconf that attempts to use the machinery. What do you think? -- Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
