libtool issues

Stephen Montgomery-Smith stephen at
Mon Jun 20 15:01:30 UTC 2011

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:
>> 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/  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++
>> Or one could instead modify devel/libtools, maybe something like this.
>> Rename bin/libtool to libexec/, 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/ $@
>> 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.


More information about the freebsd-ports mailing list