gnu make 4.3 breaks the build

Natanael Copa ncopa at alpinelinux.org
Mon Jan 27 22:01:56 UTC 2020


Hi!

On Mon, 27 Jan 2020 21:26:17 +0100
Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:

> On 2020-01-27 12:37, Natanael Copa wrote:
> > Hi,
> >
> > this is a follow up on https://mail.openjdk.java.net/pipermail/build-dev/2020-January/026635.html
> >
> > Alpine linux has bumped into the same issue and it sort of blocking the
> > security update. I would rather try fix the make issue than roll back
> > to make 4.2.1.
> >
> > Downstream mergerequest/report:
> > https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3224
> >
> > It fails on different location even if I run it with JOBS=1, so to
> > track it down I had to run make clean between each run.
> >
> > This is the command that fails (I have manually inserted the --debug --trace options):  
> Thanks for the debugging help.
> 
> I looked at the alpine bug report -- at this point I would not consider 
> this a make bug, since it's more likely that we've got caught on one of 
> their changes. But it might be a regression in make, too. (But even in 
> that case, I'm afraid we'll have to work around it.)

I filed a bug to make as well.

> > If I re-run the command (without make clean) it will succeed:  
> My preliminary analysis indicated a problem with our MakeDir macro, 
> which is basically a sophisticated way of calling mkdir -p. If a rerun 
> succeeded, this definitely corroborates this story. It might be a couple 
> of days before I have time to look further into this issue. If you want 
> to delve deeper, have a look at make/common/MakeBase.gmk, especially 
> DependOnVariable and MakeDir.

I think you are right. I was able to create a test case which I
submitted to gnu make bug tracker.

https://savannah.gnu.org/bugs/index.php?57676

Thank you for quick response.

-nc



More information about the build-dev mailing list