From owner-freebsd-questions@FreeBSD.ORG Fri Jun 11 13:14:05 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6119E16A4CE for ; Fri, 11 Jun 2004 13:14:05 +0000 (GMT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D179043D45 for ; Fri, 11 Jun 2004 13:14:04 +0000 (GMT) (envelope-from henrik.w.lund@broadpark.no) Received: from broadpark.no (52.80-202-129.nextgentel.com [80.202.129.52]) by mail.broadpark.no (Postfix) with ESMTP id E364A4713 for ; Fri, 11 Jun 2004 15:14:16 +0200 (MEST) Message-ID: <40C9B012.90207@broadpark.no> Date: Fri, 11 Jun 2004 15:13:54 +0200 From: Henrik W Lund User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040410 X-Accept-Language: no, en-us, en MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <40C8E560.3060104@broadpark.no> In-Reply-To: <40C8E560.3060104@broadpark.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Headaches from auto* and libtool... (FOLLOW_UP) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 13:14:05 -0000 Henrik W Lund wrote: > Greetings, list! > > 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 > following message: > > ... > 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. :-) Cheers! -Henrik W Lund