Re: Migrating from 1.5.x to 2.2.x
Dan Nicholson wrote: On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl wrote: Ralf Wildenhues wrote: Hello Jason, * Jason Curl wrote on Thu, Dec 11, 2008 at 10:19:57PM CET: Ignoring that my macro obviously won't work with 2.2.x, I'm using Cygwin and I've come across my first problem. The old libtool is removed (1.5.27a) and the new is installed (at least I think the old is removed). I deleted my aclocal.m4 file and I autoreconf. I do see that the new libtool is being picked up by autotools as when configure I get errors where I'd expect and it knows not to check for C++ or Fortran anymore. "config.lt" generates the file "libtool" and thats where things start to get stuck. 'get stuck' is pretty vague. Please make it more specific by posting the command you issued, and cut-and-pasting its output. Since you seem to have a macro that interferes with Libtool macros, please post it, too (or a link if it's large or you've already posted it). Showing contents of configure.ac can help, too, but I'd be able to tell better with more information. OK - a "libtoolize" works around the problem. And "./libtool --version" now shows 2.2.6. I would bet that you ran bare autoreconf. libtoolize is only run when you pass --install to autoreconf. As Ralf points out, passing --verbose to autoreconf can be very helpful while producing little extra output. You're right, I only ran "autoreconf". "libtoolize" fixed the problem. A concern I have about "libtoolize", it copies "libtool.m4" and lt*.m4 files to my "m4" macro directory. This is OK so long as all development platforms where I might run "autoreconf" are configured the same. I've tested to autoreconf my project on Ubuntu 8.10 that has by default libtool-2.2.4, where my Cygwin installation has libtool-2.2.6a. If I go backwards I get warnings. And I've already had a problem that during building the software the libtool scripts hung. All this occurs as soon as when the macros in m4/lt*.m4 don't match that which are installed on the local machine. I never had this issue with libtool-1.5.23 to libtool-1.5.26. Also what irks at the moment, is where does the libtool-1.5.x libtool that is generated by configure come from, if I don't have the m4/lt*.m4 macros in my project? Do I still have an installation problem? I was hoping these libtool macros don't need to be part of my project and would be pulled from the installation. That way it's always guaranteed to be using the right macros when I run autoreconf. In that regard, I miss having libtool-1.5. It was simpler. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Migrating from 1.5.x to 2.2.x
Jason Curl wrote: Dan Nicholson wrote: On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl wrote: Ralf Wildenhues wrote: [SNIP] You're right, I only ran "autoreconf". "libtoolize" fixed the problem. A concern I have about "libtoolize", it copies "libtool.m4" and lt*.m4 files to my "m4" macro directory. This is OK so long as all development platforms where I might run "autoreconf" are configured the same. I've tested to autoreconf my project on Ubuntu 8.10 that has by default libtool-2.2.4, where my Cygwin installation has libtool-2.2.6a. If I go backwards I get warnings. And I've already had a problem that during building the software the libtool scripts hung. All this occurs as soon as when the macros in m4/lt*.m4 don't match that which are installed on the local machine. I never had this issue with libtool-1.5.23 to libtool-1.5.26. I always had this issue with version < 2.x on all projects that include libtool macros in acinclude.m4. This is the case when user try to recreate autotools scripts. Work around is known - manually(!) remove (replace) libtool macros from acinclude.m4. As from 2.x libtool team recommend macros to be in separate files and now is more easy to refresh them. Also this isn't only libtool issue. In a project all macros from and external(dependent) has to be synchronized with you version of this package. If macros rare from new or old version is possible configure script to fail. This is integration problem(issue). Overwriting external m4 files in a project with those from system help in most cases, but not all. The hang of libtool may be is similar to KDevelop issue : http://lists.gnu.org/archive/html/bug-libtool/2008-05/msg00086.html [SNIP] Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Migrating from 1.5.x to 2.2.x
Roumen Petrov wrote: Jason Curl wrote: Dan Nicholson wrote: On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl wrote: Ralf Wildenhues wrote: [SNIP] You're right, I only ran "autoreconf". "libtoolize" fixed the problem. A concern I have about "libtoolize", it copies "libtool.m4" and lt*.m4 files to my "m4" macro directory. This is OK so long as all development platforms where I might run "autoreconf" are configured the same. I've tested to autoreconf my project on Ubuntu 8.10 that has by default libtool-2.2.4, where my Cygwin installation has libtool-2.2.6a. If I go backwards I get warnings. And I've already had a problem that during building the software the libtool scripts hung. All this occurs as soon as when the macros in m4/lt*.m4 don't match that which are installed on the local machine. I never had this issue with libtool-1.5.23 to libtool-1.5.26. I always had this issue with version < 2.x on all projects that include libtool macros in acinclude.m4. This is the case when user try to recreate autotools scripts. Work around is known - manually(!) remove (replace) libtool macros from acinclude.m4. As from 2.x libtool team recommend macros to be in separate files and now is more easy to refresh them. Also this isn't only libtool issue. In a project all macros from and external(dependent) has to be synchronized with you version of this package. If macros rare from new or old version is possible configure script to fail. This is integration problem(issue). Overwriting external m4 files in a project with those from system help in most cases, but not all. I guess this would only be a problem when using undocumented features of the autotools. I still don't know why autoreconf couldn't find the libtool.m4, lt*.m4 packages directly from it's own /usr/share/libtool (or similar) repository that is guaranteed to match the libtool that is installed, instead of having to have a symbolic link to that installation location in anycase. As I posted in an earlier post, if I don't have these m4 macros, configure generates a libtool in the current directory that says its version 1.5.26, so it appears I must do it the way libtoolize wants. The hang of libtool may be is similar to KDevelop issue : http://lists.gnu.org/archive/html/bug-libtool/2008-05/msg00086.html Similar, but between libtool-2.2.4 (Ubuntu 8.10) and libtool-2.2.6 (Cygwin 1.5.x) Thanks for your tips Roumen. ___ http://lists.gnu.org/mailman/listinfo/libtool
