r876227 remove detection for GNU libtool and made Subversion use APR's libtool instead. r876296 added an option --with-custom-libtool that allows users to specify an alternative libtool to use. The problem: None of these options allow everyone to get a working build. E.g. on OpenSUSE, APR's libtool is configured such that is does not support C++. So Subversion fails to build the kwallet support libraries. The standard libtool shipped with OpenSUSE does not work as expected either. We run into a build issue similar to the one reported here: https://bugzilla.novell.com/show_bug.cgi?id=649983 cd subversion/libsvn_auth_kwallet && /usr/bin/libtool --tag=CXX --mode=link g++ -shared -pie -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fPIC -Wall -fno-strict-aliasing -DLDAP_DEPRECATED -Wall -g -fpie -fstack-protector -pie -L/usr -rpath /usr/lib -Wl,--no-undefined -o libsvn_auth_kwallet-1.la kwallet.lo version.lo -lapr-1 -ldbus-1 -lpthread -lrt -lQtCore -lQtDBus -lQtGui -lkdecore -lkdeui ../../subversion/libsvn_subr/libsvn_subr-1.la libtool: link: unsupported hardcode properties libtool: link: See the libtool documentation for more information. libtool: link: Fatal configuration error. The problems seems to be that nothing calls LT_INIT when a custom libtool is used. There was a call to LT_INIT before r876227. Adding it back also requires adding AC_PROG_LIBTOOL back, which apparently means calling libtoolize from autoconf.sh. This effectively means that we'd have to revert r876227 to get a working build on such systems.