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)
Hrm ... this is a problem. Ill fix it asap.
Should be fixed in libtool-1.4.1-portage.patch-v5, included in libtool-1.4.1-r8, thanks.
Verified fixed in libtool-1.4.1-r8
