[Top][All Lists]

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

Re: Migrating from 1.5.x to 2.2.x

From: Jason Curl
Subject: Re: Migrating from 1.5.x to 2.2.x
Date: Sun, 14 Dec 2008 21:55:42 +0100
User-agent: Thunderbird (Windows/20081105)

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:
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 :
Similar, but between libtool-2.2.4 (Ubuntu 8.10) and libtool-2.2.6 (Cygwin 1.5.x)

Thanks for your tips Roumen.

reply via email to

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