Re: bug#18910: GNU Libtool-2.4.3 released [stable]

[Gary V. Vaughan]

Hi Pavel,

Sorry the lists are being slow this weekend :(

> On Oct 30, 2014, at 1:06 PM, Pavel Raiskup <address@hidden> wrote:
> 
> Thanks for the release, Gary and all!
> 
> On Monday 27 of October 2014 21:44:02 Gary V. Vaughan wrote:
>> - Fix a long-standing bug when using libtoolize without automake; we
>>   no longer remove install-sh with --force, since it's not a file
>>   libtoolize will reinstall without --install.
> 
> It is not completely the same situation like with automake, but
> gnulib-origin files are causing similar problems [1].
> 
> Taking into account the package relies on some gnulib files in question
> itself (not via libtool), the package should still be easily autoreconfed
> from distributed tarballs with (relatively) safe command
> 'autoreconf -vfi'.
> 
> However now (a) libtoolize removes gnulib files and (b) build machine (or
> the user) may have no idea what gnulib is when working with 'make dist'ed
> tarball.  If there is no reason for current libtoolize to install those
> files, the patch attached could help.  That is not a solution for
> "upgrade" cleanup but can there be other safe solution?

I agree with your patch though, and pushed it just now.  Thank you!

> Also, I'm not sure what to do with 'argz.m4'.  That file can be updated by
> package maintainer via gnulib-tool, however libtool (via autoreconf -vfi
> e.g.) can overwrite it with older version of this file.  That however does
> not break the build, at least not now.

I wrote argz.m4 for libtool, and later contributed it back to gnulib.  Ideally,
libtool would just use gnulib's argz module, but doing so pulls in an insane
amount of cruft (including the various snippet files) that I don't want to
have to teach libtoolize to manage - that's why I gave up on trying to gnulibize
libltdl, and why we had some interim releases of libtoolize fighting with
gnulib-tool over who owns the snippet files :)

A better solution would be to fork libtool's argz.m4 by moving it into the
LT_ namespace so it doesn't conflict with any gnulib version used by the parent
project.  Bleh!

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)