This line of the patch:
install_libdir="`echo "$install_libdir" |sed -e "s:${D}::g" -e 's://:/:g'`"
results in an syntax error when $D is undefined (presumably, anytime libtool is
not operating inside of ebuild) and causes install_libdir to be cleared. This
breaks anything attempting to link against the libtool library after it's been
installed. In my case, I contribute to both apache-2.0 and subversion, and this
bug causes a broken install of libapr that results in subversion being unable to
link. My wager is that pretty much anything that uses libtool outside of an
ebuild would be broken by this.
I added some echos around this to illustrate what's going on:
/bin/sh /home/stephenc/devel/bleeding-edge/httpd-2.0/srclib/apr/libtool ...
...
install_libdir before: /home/stephenc/bin/apache-2.0/lib
about to execute: echo "/home/stephenc/bin/apache-2.0/lib" |sed -e "s:::g" -e
's://:/:g'
sed: -e expression #1, char 5: No previous regular expression
install_libdir after:
In reality this shouldn't have changed at all.
The simple fix seems to be just adding something to check that we're actually
being called by ebuild before attempting to apply all these hacks. Just as a
case in point I wrapped the offending code inside `if test "$D" != ""` and
libtool now does the Right Thing in my case. But $D seems like a bad variable
to check (theoretically it could be used elsewhere by the user as a temp
variable of some sort; something more obviously specific to ebuild should
probably be used)