Roumen Petrov wrote:
Jason Curl wrote:
Dan Nicholson wrote:
On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl <[email protected]>
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
