Re: Migrating from 1.5.x to 2.2.x

[Jason Curl]

Roumen Petrov wrote:
> Jason Curl wrote:
> > Dan Nicholson wrote:
> > > On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl <address@hidden> 
> > > 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.