First of all I'm not aware of any case when this can cause build failures. The following test from autotools.eclass:_elibtoolize() doesn't work in some cases with libtool-2.4.3: if [[ $1 == "--install" ]] ; then ${LIBTOOLIZE} -n --install >& /dev/null || shift fi One of the examples is apr: vm3020 apr-1.5.0 # libtoolize -n --install rm -f build/config.guess libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build'. libtoolize: error: 'build/config.guess' exists: use '--force' to overwrite rm -f build/config.sub libtoolize: error: 'build/config.sub' exists: use '--force' to overwrite rm -f build/install-sh libtoolize: linking file 'build/install-sh' rm -f build/ltmain.sh libtoolize: error: 'build/ltmain.sh' exists: use '--force' to overwrite rm -f build/libtool.m4 libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'build'. libtoolize: error: 'build/libtool.m4' exists: use '--force' to overwrite rm -f build/ltoptions.m4 libtoolize: error: 'build/ltoptions.m4' exists: use '--force' to overwrite rm -f build/ltversion.m4 libtoolize: error: 'build/ltversion.m4' exists: use '--force' to overwrite libtoolize: Consider adding '-I build' to ACLOCAL_AMFLAGS in Makefile.am. libtoolize: 'AC_PROG_RANLIB' is rendered obsolete by 'LT_INIT' vm3020 apr-1.5.0 # echo $? 1 However without "-n" it works fine: vm3020 apr-1.5.0 # libtoolize --install libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build'. libtoolize: linking file 'build/config.guess' libtoolize: linking file 'build/config.sub' libtoolize: linking file 'build/install-sh' libtoolize: linking file 'build/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'build'. libtoolize: linking file 'build/libtool.m4' libtoolize: linking file 'build/ltoptions.m4' libtoolize: linking file 'build/ltversion.m4' libtoolize: Consider adding '-I build' to ACLOCAL_AMFLAGS in Makefile.am. libtoolize: 'AC_PROG_RANLIB' is rendered obsolete by 'LT_INIT' vm3020 apr-1.5.0 # echo $? 0
Created attachment 389202 [details, diff] 0001-libtoolize-skip-destfile-existence-check-in-dry-run-.patch Possible fix
if you've gone through the effort of writing a proper patch, you could just send it directly to the libtool guys :) https://lists.gnu.org/mailman/listinfo/libtool-patches
Currently I don't think it's a proper patch. func_copy() should skip the existence check only if the destfile was previously "removed" by '$RM "$my_destfile"' which is not always true. So my patch is more like a workaround.
(In reply to Alexander Tsoy from comment #0) > First of all I'm not aware of any case when this can cause build failures. Oh. We have at least one package which suffer from this issue: bug 529014 :)
(In reply to Alexander Tsoy from comment #3) the worst that would happen is they say no, and then they'd fix it themselves in a different way ;) (In reply to Alexander Tsoy from comment #4) we can probably just the eclass to force recent libtool versions and then drop the logic that probes the version
libtoolize now always uses --install and forces libtool-2.4+ http://sources.gentoo.org/eclass/autotools.eclass?r1=1.163&r2=1.164
*** Bug 529014 has been marked as a duplicate of this bug. ***
guess it's a non-issue for us now in the tree
