GNU bug report logs - #18910
GNU Libtool-2.4.3 released [stable]

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18910 in the body.
You can then email your comments to 18910 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pavel Raiskup <praiskup <at> redhat.com>
To: libtool <at> gnu.org, bug-libtool <at> gnu.org
Subject: Re: GNU Libtool-2.4.3 released [stable]
Date: Thu, 30 Oct 2014 14:06:05 +0100

[Message part 1 (text/plain, inline)]

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?

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.

[1] https://bugs.gentoo.org/show_bug.cgi?id=527200

Pavel

[0001-libtoolize-do-not-remove-gnulib-files-with-force.patch (text/x-patch, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Pavel Raiskup <praiskup <at> redhat.com>
Cc: libtool <at> gnu.org, bug-libtool <at> gnu.org
Subject: Re: GNU Libtool-2.4.3 released [stable]
Date: Fri, 31 Oct 2014 20:47:33 -0400

[Message part 1 (text/plain, inline)]

On 30 Oct 2014 14:06, Pavel Raiskup wrote:
> 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].

i posted largely the same thing to the patch list:
	https://lists.gnu.org/archive/html/libtool-patches/2014-10/msg00018.html
-mike

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 18910 <at> debbugs.gnu.org (full text, mbox):

From: "Gary V. Vaughan" <gary <at> vaughan.pe>
To: Pavel Raiskup <praiskup <at> redhat.com>
Cc: 18910 <at> debbugs.gnu.org, libtool <at> gnu.org
Subject: Re: bug#18910: GNU Libtool-2.4.3 released [stable]
Date: Sun, 2 Nov 2014 12:10:42 +0000

Hi Pavel,

Sorry the lists are being slow this weekend :(

> On Oct 30, 2014, at 1:06 PM, Pavel Raiskup <praiskup <at> redhat.com> 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)

Message #16 received at 18910-done <at> debbugs.gnu.org (full text, mbox):

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: 18903-done <at> debbugs.gnu.org, 18910-done <at> debbugs.gnu.org,
 18916-done <at> debbugs.gnu.org, 19633-done <at> debbugs.gnu.org,
 19881-done <at> debbugs.gnu.org
Subject: bug#18903, bug#18910, bug#18916, bug#19633, bug#19881: Closing stale
 resolved bugs
Date: Thu, 17 Oct 2024 17:58:15 +0300

[Message part 1 (text/plain, inline)]

These bug reports are either not bugs or were resolved a decade ago.

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]

[OpenPGP_signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.