Jason Curl wrote:
Dan Nicholson wrote:
On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl <jcurln...@arcor.de> 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