libtool issues

b. f. bf1783 at
Mon Jun 20 22:16:32 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.

As I told you when this came up some months ago, and Kostik has noted
again, libtool caches more than just the name of the compiler -- there
are also other important bits of information that may need to be
preserved. Unless there are some changes upstream to accommodate
different toolchains at run-time, I think that making separate libtool
ports for each compiler that is widely-used in Ports is the best
solution, even though it is a nuisance to do so.  Another alternative
would be to alter the autotools infrastructure so that a temporary
libtool was built for each port that needed it, using the compiler
specified for the port, as is now done by some ports that use a
bundled version of libtool, but this would somewhat prolong builds.
The main problem with either of these alternatives is to uncouple the
devel/libltdl port from libtool, because this port installs shared
libraries that may be needed after some port builds, at run-time.  I
haven't looked at whether different versions of libltdl would also be
needed.  If so, the patching and renaming required to point ports to
different versions of those libraries would be the main obstacle.

Here is a rough version that I use as a workaround on my system, for
gcc46.  I didn't make the necessary changes to libltdl, because I
didn't need them.  Also, I didn't bother to save space by unifying the
separate 'plists.

-------------- next part --------------
A non-text attachment was scrubbed...
Type: application/octet-stream
Size: 1613 bytes
Desc: not available
Url :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libtool.diff
Type: application/octet-stream
Size: 5756 bytes
Desc: not available
Url :

More information about the freebsd-ports mailing list