Hi! On Mon, 27 Jan 2020 21:26:17 +0100 Magnus Ihse Bursie <magnus.ihse.bur...@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
