From owner-freebsd-ports@FreeBSD.ORG Mon Jun 20 15:01:30 2011 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23FAD106566C; Mon, 20 Jun 2011 15:01:30 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id F2D568FC16; Mon, 20 Jun 2011 15:01:29 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.4/8.14.4) with ESMTP id p5KF1SgS082879; Mon, 20 Jun 2011 10:01:29 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4DFF60C8.2070705@missouri.edu> Date: Mon, 20 Jun 2011 10:01:28 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kostik Belousov References: <4DFEE295.3090204@missouri.edu> <20110620091608.GG48734@deviant.kiev.zoral.com.ua> In-Reply-To: <20110620091608.GG48734@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ports@FreeBSD.org" , Stas Timokhin , "ade@freebsd.org" Subject: Re: libtool issues X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:01:30 -0000 On 06/20/2011 04:16 AM, Kostik Belousov wrote: > On Mon, Jun 20, 2011 at 01:03:01AM -0500, Stephen Montgomery-Smith wrote: >> I am maintainer of the science/vis5d+ port. It doesn't build on the >> i386 with FreeBSD-8.0-RELEASE, as is shown here: >> >> http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/a.8.20110223062852/vis5d+-1.2.1_15.log >> >> I know that other ports have this problem such as science/libctl. This >> port is currently marked broken for exactly this reason. >> >> I have a work around at this PR: ports/155105. This work around was >> improved in ports/155655 (see the follow up comment by the maintainer, >> who submits a patch to libctl). >> >> I also reported the problem at ports/155546, although I don't think my >> solution there is very good, and my description of the bug wa very >> incomplete. Furthermore, it turns out that this problem does not take >> place under the FreeBSD-8.2-STABLE. This can make the problem a little >> bit hard to diagnose. Nevertheless I can see this problem recurring >> systematically again in the future, because libtool was not designed for >> multiple compiler environments. >> >> It would be great to find a work around. One way would be to put in >> some kind of construction like ports/155105 or ports/155655 into >> Mk/bsd.autotools.mk. So whenever the port has USE_LIBTOOLS set, we have >> the following code >> >> LIBTOOLS_DIR=${WRKDIR}/.libtools.dir.${PORTNAME}.${PREFIX:S/\//_/g} >> ${LN} -s ${LOCALBASE}/bin/${CC} ${LIBTOOLS_DIR}/cc >> ${LN} -s ${LOCALBASE}/bin/${CXX} ${LIBTOOLS_DIR}/c++ >> MAKE_ENV+= PATH=${LIBTOOLS_DIR}:$$PATH >> >> Or one could instead modify devel/libtools, maybe something like this. >> Rename bin/libtool to libexec/libtool.sh, and then rewrite the libtool >> script as something like: >> >> #!/bin/sh >> PREFIX=/usr/local >> TEMPCCDIR=`mktemp -d -t /tmp` >> export PATH=${WRKDIR}:$PATH >> ${LN} -s ${LOCALBASE}/bin/${CC} ${TEMPCCDIR}/cc >> ${LN} -s ${LOCALBASE}/bin/${CXX} ${TEMPCCDIR}/c++ >> ${PREFIX}/libexec/libtool.sh $@ >> rm -r ${TEMPCCDIR} >> >> I know these are real hacks. But since we are trying to patch something >> into libtool that it really isn't designed for, perhaps my hackish >> approach has advantages. In particular, one doesn't have to redesign >> different patches every time there is a libtool version update. >> >> Just some ideas. In the meantime, do you think it is OK to commit >> ports/155105 and the libctl part of ports/155655? It would be nice to >> get these ports working again on the i386, at least on a temporary basis. > > The libtool binding to the compiler is done for the reason. Your hack > will cause more subtle breakage, since it causes libtool to be used with > compiler with different internals. In particular, libtool overrides the > linking stage arguments, manually providing crt* objects. This is what > breaks your ports, but the hack has the same undefined consequences > there. You are just lucky that you do not see them. I must admit that I am just "trying things out." But based up what you said, I think I can now see why this would be a problem. > Wouldn't it be easier to have per-compiler libtool port ? > devel/libtool for the base compiler, devel/libtool-gcc45 for lang/gcc45, > probably devel/libtool-clang_base for clang from base and so on. That would be great if someone were willing to do the work. To be honest, I don't fully comprehend how libtool really works, so I couldn't do it. Stephen