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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
