I also hit this bug. As a workaround, enabling fast install (by e.g. passing --enable-fast-install to configure) seems to be enough to solve the problem, since binaries don't need to be relinked during installation.

This issue affects all versions of libtool from 2.2.10 going back to the initial versions that added support for DESTDIR installs. 

Consider a package "package-1.0", which includes two libraries "liba" and "libb".  liba has a function named "a_1", and libb requires this function and is linked against liba.  package-1.0 gets installed on a system and everyone is happy.

Now package-2.0 comes out.  "liba" now has a new function "a_2", and libb now uses both "a_1" and "a_2".

When compiling package-2.0, libb will correctly link against the liba that's included in package-2.0.

If you just "make install", libb will be correctly relinked, because liba will get installed in the final location first.

HOWEVER, if you do a "DESTDIR" install, the relink step for libb will fail, because libtool doesn't prepend the DESTDIR library directory to the library search path, so when libb is relinked, it finds the liba from package-1.0 that's already installed on the system.  Since the 1.0 version of liba doesn't have function "a_2", the relink fails.

This issue has been reported on the libtool mailing list several times, e.g.

http://lists.gnu.org/archive/html/libtool/2003-02/msg00098.html

http://lists.gnu.org/archive/html/libtool/2003-05/msg00022.html

http://lists.gnu.org/archive/html/libtool/2009-11/msg00010.html

http://lists.gnu.org/archive/html/libtool/2002-11/msg00112.html

I can find more instances in the mailing lists if necessary, but you get the point.  It's affected a lot of people, and it's a real hassle for people that do software packaging with something like RPM or apt.