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.
Major