Date: Mon, 20 Jun 2011 10:01:28 -0500 From: Stephen Montgomery-Smith <stephen@missouri.edu> To: Kostik Belousov <kostikbel@gmail.com> Cc: "ports@FreeBSD.org" <ports@freebsd.org>, Stas Timokhin <devel@stasyan.com>, "ade@freebsd.org" <ade@freebsd.org> Subject: Re: libtool issues Message-ID: <4DFF60C8.2070705@missouri.edu> In-Reply-To: <20110620091608.GG48734@deviant.kiev.zoral.com.ua> References: <4DFEE295.3090204@missouri.edu> <20110620091608.GG48734@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DFF60C8.2070705>