Graeme Hewson wrote:
This is due to a bug in libtool, fixed in version 1.5.20. Is there any
reason not to have autogen.sh check for libtool version >= 1.5.20, as it
checks now for version >= 1.4? (Incidentally, configure.in could be
simplified with version 1.5.20.)
If a large number of releases of {Linux distributions, BSD versions
including OS X, other OSes that bundle libtool or otherwise provide them
with the development tool set} that are still being used supply older
versions, that might be a reason not to have it check for 1.5.20,
especially if:
Unfortunately, if someone encounters this problem, it's not sufficient
to install the latest version of libtool in /usr/local, say, with $PATH
set appropriately to override the older version in /usr.
...people with one of those releases can't make Ethereal build from SVN
on their system merely by installing the new version of libtool.
Somewhere
along the line, libtool invokes the aclocal perl script, part of
Automake, which hardwires the aclocal directory. E.g., if aclocal is
installed in /usr/bin, it includes the line:
> $acdir = '/usr/share/aclocal';
which means that /usr/share/aclocal/libtool.m4 is invoked instead of the
latest version installed in /usr/local/share/aclocal/libtool.m4.
Perhaps installing automake and autoconf in /usr/local would work around
that, but it'd *still* be a pain - some developers might be able to
update to a later version of the {Linux distribution, BSD version, etc.}
that they're running, but if this version of libtool isn't good enough:
$ glibtool --version
ltmain.sh (GNU libtool) 1.5 (1.1220 2003/04/05 19:32:58)
it's not as if I can upgrade to OS X 10.5.0 (assuming it, or the
development tools release that comes with, will have a newer version of
libtool) - it's not out yet. (And I'm not sure what would break if
"/usr/local/bin" had a version of libtool, as it'd be incompatible with
the "libtool" on the machine - not "incompatible" as in "can't handle
libtool stuff", but "incompatible" as in "doesn't even do the same thing":
$ man libtool
NAME
libtool - create libraries
ranlib - add or update the table of contents of archive libraries
SYNOPSIS
libtool -static -o output [ -sacLT ] [ - ] [ -arch_only
arch_type ]
file... [-filelist listfile[,dirname]]
libtool -dynamic -o output [ -install_name name ] [
-compatibility_ver-
sion number ] [ -current_version number ] [ link editor flags ]
[ -v ]
[ -noall_load ] [ - ] [ -arch_only arch_type ] [ -V ]
file...
[-filelist listfile[,dirname]]
ranlib [ -sactfqLT ] [ - ] archive...
DESCRIPTION
The libtool command takes the specified input object files and
creates
a library for use with the link editor, ld(1). The library's
name is
specified by output (the argument to the -o flag). The input
object
files may be in any correct format that contains object files
(``fat''
files, archives, object files). Libtool will not put any
non-object
input file into the output library (unlike ranlib, which allows
this in
the archives it operates on).
which is why GNU libtool is called "glibtool" in OS X - I suspect the OS
X libtool antedates GNU libtool, as it might date back to the old
NeXTStEP of which OS X is a descendant.)
And even if the developer *can* upgrade to a later release of their OS,
they might not want to - they might have other reasons for continuing to
run an older release.
