Re: bug#22702: [bug-grep] grep-2.23 build feedback

[Jim Meyering]

On Thu, Sep 8, 2016 at 7:20 PM, Paul Eggert  wrote:
> Jim Meyering wrote:
>>
>> I actually wrote a patch to fix the automake bug that led to this,
>> but did not find the time to write a stand-alone test case.
>> Today, I wrote the commit log entry and am attaching the
>> incomplete diff (no NEWS and no test) here, in case someone
>> wants to help move this along before I find time.
>
> Thanks, I installed that patch into automake (Savannah micro branch).
>
> This should fix Bug#21815 so I'll close that bug report while I'm at it.

Thanks, Paul.

Re: bug#22702: [bug-grep] grep-2.23 build feedback

[Paul Eggert]

Jim Meyering wrote:

I actually wrote a patch to fix the automake bug that led to this,
but did not find the time to write a stand-alone test case.
Today, I wrote the commit log entry and am attaching the
incomplete diff (no NEWS and no test) here, in case someone
wants to help move this along before I find time.


Thanks, I installed that patch into automake (Savannah micro branch).

This should fix Bug#21815 so I'll close that bug report while I'm at it.

Re: bug#22702: [bug-grep] grep-2.23 build feedback

[Jim Meyering]

On Tue, Feb 16, 2016 at 9:34 AM, Nelson H. F. Beebe  wrote:
...
Thank you for all of the feedback.
I agree that many of the failures are due to inadequate library
support, and we should eventually improve the tests to detect
the inferior interfaces and diagnose them as such. However,
that is not on my short list, for now.

> In addition, compilation on MacOS X 10.10 (Yosemite) and 10.11 (El
> Capitan) produces these warnings from clang masquerading as gcc:
>
> make[3]: Entering directory 
> '/private/var/tmp/build/bare/grep-2.23/lib'
> Makefile:1684: target '.deps/alloca.Po' given more than once in the 
> same rule
>   CC   argmatch.o

I actually wrote a patch to fix the automake bug that led to this,
but did not find the time to write a stand-alone test case.
Today, I wrote the commit log entry and am attaching the
incomplete diff (no NEWS and no test) here, in case someone
wants to help move this along before I find time.
From 7a5fb319e557a94b64785d4312ceda197e317248 Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Thu, 18 Feb 2016 09:19:44 -0800
Subject: [PATCH] do not emit rule with two .deps/alloca.Po dependents

On a system using our replacement alloca, make would emit
this warning:
  target '.deps/alloca.Po' given more than once in the same rule
That arose because automake would emit a rule depending on both
./.deps/alloca.Po and .deps/alloca.Po. Normally, duplicate
dependents are avoided by virtue of their names being keys in
the %dep_files hash, but in this case, that particular file
was specified in two different ways.
* bin/automake.in (handle_ALLOCA): When the $dir prefix is empty,
make it './', to ensure that when we add ./.deps/alloca.Po
it is deduped.
---
 bin/automake.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bin/automake.in b/bin/automake.in
index c1d1a8a..7508bc2 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -2208,6 +2208,7 @@ sub handle_ALLOCA
   $lt ||= '';
   my $dir = handle_LIBOBJS_or_ALLOCA "${lt}ALLOCA";

+  $dir eq '' and $dir = './';
   $var->requires_variables ("\@${lt}ALLOCA\@ used", $lt . 'ALLOCA');
   $dep_files{$dir . '$(DEPDIR)/alloca.P' . $myobjext} = 1;
   require_libsource_with_macro ($cond, $var, FOREIGN, 'alloca.c');
-- 
2.6.4