devel/libtool15 unconditionally hardcodes autodetected textproc/gsed
shuvaev at physik.uni-wuerzburg.de
Mon Sep 8 23:35:50 UTC 2008
While the ports are in freeze just want to point to the problem I have
encountered. Not sure if this is a critical bug, just a bug or not
a bug at all (so, no PR yet).
If one installs/rebuilds devel/libtool15 while textproc/gsed is
installed, libtool autodetects it and hardcodes gsed in itself.
If later one removes gsed (and nothing prevents him from doing this),
libtool is left in a broken state. FWIW, textproc/gsed is a BUILD_DEPENDS
of some ports.
Ideally, I think, one should hack libtool's configure framework to
not detect gsed at all. Sorry, no patch here. Attached is the diff
between unpacked libtool packages, one built with system sed and
one - with gsed.
-------------- next part --------------
diff -ruN libtool-good/+CONTENTS libtool-bad/+CONTENTS
--- libtool-good/+CONTENTS 2008-09-08 10:29:34.000000000 +0200
+++ libtool-bad/+CONTENTS 2008-09-08 20:50:41.000000000 +0200
@@ -4,7 +4,7 @@
@comment $FreeBSD: ports/devel/libtool15/pkg-plist,v 1.13 2006/02/23 10:36:03 ade Exp $
- at comment MD5:d82d18482a1bdb6a66b4a88e5f6af477
+ at comment MD5:553962c30b1587c8cd17cd90a252a8f2
diff -ruN libtool-good/bin/libtool libtool-bad/bin/libtool
--- libtool-good/bin/libtool 2008-09-08 10:29:29.000000000 +0200
+++ libtool-bad/bin/libtool 2008-09-08 20:50:36.000000000 +0200
@@ -30,10 +30,10 @@
# the same distribution terms that you use for the rest of that program.
# A sed program that does not truncate output.
# Sed that helps us avoid accidentally triggering echo(1) options like -n.
-Xsed="/usr/bin/sed -e 1s/^X//"
+Xsed="/usr/local/bin/gsed -e 1s/^X//"
# The HP-UX ksh and POSIX shell print the target directory to stdout
# if CDPATH is set.
More information about the freebsd-ports