[PATCH] Fix build with GNU Make 3.81

[PATCH] Fix build with GNU Make 3.81

[Bernd Edlinger]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

Hi,

I have a minor problem with building the gdbserver, alloc-ipa.o
on ubuntu 14.04 which still uses GNU Make 3.81.

Since several quirks for this GNU Make version exist, I suppose
this version is still intended to be supported.

This patch fixes the build with this make version, and works
also for newer versions.


Thanks
Bernd.

[-- Attachment #2: changelog.txt --]
[-- Type: text/plain, Size: 117 bytes --]

gdb/gdbserver:
2019-12-14  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	* Makefile.in: Fix build with GNU Make 3.81

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-Fix-build-with-GNU-Make-3.81.patch --]
[-- Type: text/x-patch; name="0001-Fix-build-with-GNU-Make-3.81.patch", Size: 2607 bytes --]

From 324a036bd552186baa9ea16d7ac0072d74220f35 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date: Fri, 13 Dec 2019 17:21:21 +0100
Subject: [PATCH] Fix build with GNU Make 3.81

GNU Make 3.81 is apparently confused when the same
source file is processed by a pattern rule and an
explicit rule at the same time with different output file.
The pattern %.o: ../%.c and alloc-ipa.o: ../alloc.c
both have the source ../alloc.c but two independent
object files alloc.o and alloc-ipa.o, so
while building gdbserver I see the following message:

make[4]: Circular alloc-ipa.o <- ../alloc.c dependency dropped.
  CXX    alloc-ipa.o
g++: warning: '-x c++' after last input file has no effect
g++: fatal error: no input files
compilation terminated.

In the make debug output I see the pattern is first correct:

alloc-ipa.o: ../alloc.c | config.h build-gnulib-gdbserver/import/string.h
        $(IPAGENT_COMPILE) $(WARN_CFLAGS_NO_FORMAT) $<
        $(POSTCOMPILE)

But after the "Circular" dependency is dropped, the pattern
is changed to:

alloc-ipa.o: | config.h build-gnulib-gdbserver/import/string.h
        $(IPAGENT_COMPILE) $(WARN_CFLAGS_NO_FORMAT) $<
        $(POSTCOMPILE)

So indeed now $< is empty, and the build step fails.

This happens only when alloc.o needs to be built, when alloc.o
was already built, the build succeeds, but it takes often
several attempts until the build succeeds.
By rewriting the alloc-ipa.c: ../alloc.c rule into a pattern
rule, the problem goes away.

While already at it, this patch removes also the
$(WARN_CFLAGS_NO_FORMAT) from the build rule, which is just a
copy/paste thing that is not necessary for alloc.c at all.
---
 gdb/gdbserver/Makefile.in | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gdb/gdbserver/Makefile.in b/gdb/gdbserver/Makefile.in
index 10e0040..9e8c213 100644
--- a/gdb/gdbserver/Makefile.in
+++ b/gdb/gdbserver/Makefile.in
@@ -580,10 +580,6 @@ ax.o: ax.c
 	$(COMPILE) $(WARN_CFLAGS_NO_FORMAT) $<
 	$(POSTCOMPILE)
 
-alloc-ipa.o: ../alloc.c
-	$(IPAGENT_COMPILE) $(WARN_CFLAGS_NO_FORMAT) $<
-	$(POSTCOMPILE)
-
 # Rules for objects that go in the in-process agent.
 
 arch/%-ipa.o: ../arch/%.c
@@ -602,6 +598,10 @@ gdbsupport/%-ipa.o: ../gdbsupport/%.c
 	$(IPAGENT_COMPILE) $<
 	$(POSTCOMPILE)
 
+%-ipa.o: ../%.c
+	$(IPAGENT_COMPILE) $<
+	$(POSTCOMPILE)
+
 # Note: Between two matching pattern rules, GNU Make 3.81 chooses the first one.
 # Therefore, this one needs to be before "%.o: %.c" for it to be considered for
 # files such as linux-amd64-ipa.o generated from linux-amd64-ipa.c.
-- 
1.9.1

Re: [PATCH] Fix build with GNU Make 3.81

[Simon Marchi]

On 2019-12-14 3:15 a.m., Bernd Edlinger wrote:
> Hi,
> 
> I have a minor problem with building the gdbserver, alloc-ipa.o
> on ubuntu 14.04 which still uses GNU Make 3.81.
> 
> Since several quirks for this GNU Make version exist, I suppose
> this version is still intended to be supported.
> 
> This patch fixes the build with this make version, and works
> also for newer versions.
> 
> 
> Thanks
> Bernd.
> 

Hi Bernd,

The intention was to support make >= 3.82, since this commit:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c6bdbeb7c468489da9468445057d245929c3d91c

Though it's possible that (stale) references and tweaks for make 3.81
are left.

I don't mind if we merge simple fixes like that, as long as it doesn't compromise
building with newer versions.  Like, if there was a super-duper cool feature of
make 3.82 that would really simplify our lives, we would still prefer using that
over keeping compatibility with make 3.81.

I'll let Tom decide, since he introduced that new file.

Simon

Re: [PATCH] Fix build with GNU Make 3.81

[Tom Tromey]

>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

Simon> I don't mind if we merge simple fixes like that, as long as it doesn't compromise
Simon> building with newer versions.  Like, if there was a super-duper cool feature of
Simon> make 3.82 that would really simplify our lives, we would still prefer using that
Simon> over keeping compatibility with make 3.81.

Sounds reasonable to me.

Simon> I'll let Tom decide, since he introduced that new file.

The patch looks ok to me.  Thanks.

Tom

Re: [PATCH] Fix build with GNU Make 3.81

[Joel Brobecker]

> Simon> I don't mind if we merge simple fixes like that, as long as it doesn't compromise
> Simon> building with newer versions.  Like, if there was a super-duper cool feature of
> Simon> make 3.82 that would really simplify our lives, we would still prefer using that
> Simon> over keeping compatibility with make 3.81.
> 
> Sounds reasonable to me.

FWIW: Same here.

-- 
Joel

Re: [PATCH] Fix build with GNU Make 3.81

[Tom de Vries]

On 12/14/19 7:21 PM, Simon Marchi wrote:
> On 2019-12-14 3:15 a.m., Bernd Edlinger wrote:
>> Hi,
>>
>> I have a minor problem with building the gdbserver, alloc-ipa.o
>> on ubuntu 14.04 which still uses GNU Make 3.81.
>>
>> Since several quirks for this GNU Make version exist, I suppose
>> this version is still intended to be supported.
>>
>> This patch fixes the build with this make version, and works
>> also for newer versions.
>>
>>
>> Thanks
>> Bernd.
>>
> 
> Hi Bernd,
> 
> The intention was to support make >= 3.82, since this commit:
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c6bdbeb7c468489da9468445057d245929c3d91c
> 
> Though it's possible that (stale) references and tweaks for make 3.81
> are left.
> 
> I don't mind if we merge simple fixes like that, as long as it doesn't compromise
> building with newer versions.  Like, if there was a super-duper cool feature of
> make 3.82 that would really simplify our lives, we would still prefer using that
> over keeping compatibility with make 3.81.

I don't follow this reasoning.

There's a bug in make 3.81, which we run into with the gdb build.

We then require make 3.82, such that gdb builds again for all supported
make versions.

Subsequently (that is, 3 days later) we work around the bug in make 3.81
with a gdb commit.

But we decide to still require make 3.82, even if the original reason to
do so is no longer valid, and I'm assuming we haven't started using make
3.82 features in the 3 days inbetween.

Are there other considerations at play here, that are not being made
explicit?

Because if there are not, we should update NEWS to say we support 3.81
again.

Thanks,
- Tom

Re: [PATCH] Fix build with GNU Make 3.81

[Simon Marchi]

On 2020-07-15 4:19 a.m., Tom de Vries wrote:
> I don't follow this reasoning.
> 
> There's a bug in make 3.81, which we run into with the gdb build.
> 
> We then require make 3.82, such that gdb builds again for all supported
> make versions.
> 
> Subsequently (that is, 3 days later) we work around the bug in make 3.81
> with a gdb commit.
> 
> But we decide to still require make 3.82, even if the original reason to
> do so is no longer valid, and I'm assuming we haven't started using make
> 3.82 features in the 3 days inbetween.
> 
> Are there other considerations at play here, that are not being made
> explicit?
> 
> Because if there are not, we should update NEWS to say we support 3.81
> again.
> 
> Thanks,
> - Tom
> 

Hi Tom,

Requiring make 3.82 was based on the assumption that pretty much all supported
versions of major distros had 3.82 bundled (which turned out false for SLES11).
So the simplest thing to do when it was found that GDB wouldn't build with 3.81
was just to say "don't use 3.81", rather than trying to work around the bug.

Even with the claim that we require make 3.82, if somebody provides a simple fix
(like Bernd did) to make it work again with 3.81, then I'm happy to merge it.  It
makes his life easier, and it doesn't affect mine.

If we claim in NEWS that we support 3.81 again, then we ideally have to test it
regularly and take care of any breakage.  That's not something I want to do, but
if it is something you need to support (because you need to support SLES11) and
are ready to take care of that support, then I have nothing against it.

Simon

Re: [PATCH] Fix build with GNU Make 3.81

[Tom de Vries]

On 7/15/20 3:44 PM, Simon Marchi wrote:
> On 2020-07-15 4:19 a.m., Tom de Vries wrote:
>> I don't follow this reasoning.
>>
>> There's a bug in make 3.81, which we run into with the gdb build.
>>
>> We then require make 3.82, such that gdb builds again for all supported
>> make versions.
>>
>> Subsequently (that is, 3 days later) we work around the bug in make 3.81
>> with a gdb commit.
>>
>> But we decide to still require make 3.82, even if the original reason to
>> do so is no longer valid, and I'm assuming we haven't started using make
>> 3.82 features in the 3 days inbetween.
>>
>> Are there other considerations at play here, that are not being made
>> explicit?
>>
>> Because if there are not, we should update NEWS to say we support 3.81
>> again.
>>
>> Thanks,
>> - Tom
>>
> 
> Hi Tom,
> 
> Requiring make 3.82 was based on the assumption that pretty much all supported
> versions of major distros had 3.82 bundled (which turned out false for SLES11).

Yeah.  And looking here (
https://en.wikipedia.org/wiki/SUSE_Linux_Enterprise_Server#End-of-support_schedule
), that's still supported till 31 March 2022.

> So the simplest thing to do when it was found that GDB wouldn't build with 3.81
> was just to say "don't use 3.81", rather than trying to work around the bug.
> 

Right, that made sense at that point.

> Even with the claim that we require make 3.82, if somebody provides a simple fix
> (like Bernd did) to make it work again with 3.81, then I'm happy to merge it.  It
> makes his life easier, and it doesn't affect mine.
> 

Agreed.

> If we claim in NEWS that we support 3.81 again, then we ideally have to test it
> regularly and take care of any breakage.

Test it, yes.  Take care of any breakage, if it's reasonable for
upstream sources.  If not, we always have the option of requiring 3.82
at that point.

> That's not something I want to do, but
> if it is something you need to support (because you need to support SLES11) and
> are ready to take care of that support, then I have nothing against it.

Sure, I can set make 3.81 as my default make for development builds, and
I should at least encounter any breakage that way.

Anyways, I understand now, the decision to move to 3.82 was triggered by
the 3.81 build breaker, but based on the assumption that 3.81 was not
provided by any of the major distros so nobody would need to test and
support it, and when the build breaker got fixed, that reasoning didn't
change.

It all makes sense to me now, thanks for elaborating.

Thanks,
- Tom