Henrik W Lund wrote:
I've been given headaches lately, and I believe the auto* brothers and
their buddy, libtool, to be the culprits. It all started when I
installed Anjuta, the C/C++ IDE for GNOME. What it basically does for
project management is use autoconf, automake and libtool to generate the
familiar ./configure script and its like. Now, this all works well and
good up until the configure script is run. It will fail with the
checking whether ln -s works... yes
loading cache /dev/null within ltconfig
ltconfig: you must specify a host type if you use `--no-verify'
Try `ltconfig --help' for more information
configure: error: libtool configure failed
Now, the pickle is that I've got 4 versions of libtool installed, 3 of
which are registered in the package database. I've got libtool-1.3.4
(not in the package database), libtool-1.3.5_2 (from origin
devel/libtool13), libtool-1.4.3_3 (from origin devel/libtool14) and
libtool-1.5.6 (from origin devel/libtool15). And with two versions each
of both autoconf and automake installed, I'm suspecting that an
unfortunate mix of versions of the various programs is what's causing
this failure. I've googled around all day, and the error seems to be
fairly common, but I've yet to find a clear answer.
I'll tell you what I've tried: I've tried playing with symlinking
libtool and libtoolize to different versions of libtool (as the binaries
are named libtool13, libtool14, etc), to no avail. I've tried editing
./configure, removing the --no-verify flag, but this seems to always be
replaced somehow. I've tried different macros in configure.in for
autoconf, like AC_PROG_LIBTOOL and AC_CANONICAL_HOST, but still nothing.
I've even tried different values for HOST as an environment variable.
I know it's not Anjuta, because the IDE doesn't even need to be running
for the error to occur. Basically, I'm stumped. Can anyone here help me?
What's so special about these three programs that require numerous
versions of each installed on the same system? Or can I uninstall all
the older versions, keeping only the newest? Will this even do me any good?
Thanks in advance!
-Henrik W Lund
Kinda following up on myself here, posting what I've found after several
more hours of digging around in documentation. Actually, as I'm typing
this, I found the solution.
For some reason, the autogen.sh script creates the configure script to
call ltconfig with the --no-verify flag. This causes ltconfig to rely on
having the host type passed along on the command line (something the
autogen-generated configure script does not do). The solution is simply
to pass it along to the configure script (not
--host=cpu-manufacturer-os-kernel, simply cpu-manufacturer-os-kernel).
There may be some obscure autoconf feature to prevent it from putting
the --no-verify flag into the configure script (why is there even a --no
-verify flag???), but I've yet to find one.
Anyways, since I've answered my own question, I thought I'd just as well
document it. :-)
-Henrik W Lund
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"