Thank you for the small tutorial. I've managed to find the commit that introduces the issue! It's this one: https://git.savannah.gnu.org/cgit/make.git/commit/?id=c6966b323811c37acedff05b576b907b06aea5f4 What happens now? Regards, -- Tommaso Fonda
Il giorno dom 22 nov 2020 alle ore 21:12 Kaz Kylheku (gmake) < [email protected]> ha scritto: > On 2020-11-22 10:25, Tommaso Fonda wrote: > > Also, I've built make from source and I'm close to finding the commit that > introduced the issue. For now, I can say that setting the repo's HEAD to > commit: > b13dcfe Add more GCC warnings to the maintainer build. > produces a make binary that doesn't show the issue, but setting the HEAD > to commit: > 48c8a11 (HEAD -> test) * configure.ac: Support GLIBC glob interface > version 2 > produces a binary that shows it. > > I'll continue building make from source tomorrow, I hope to be able to > find the culprit soon. > Regards, > > > Once you're in the git workflow, "git bisect" is an efficient way to find > a commit where a change in behavior took place. > > $ git bisect start > $ git checkout b13dcfe # known commit that doesn't show the issue > $ git bisect good # inform git bisect > $ git checkout 48c8a11 # known commit that shows issue > $ git bisect bad # inform git bisect > > Now git bisect should find a midway commit for you to test and jump to it. > Build it and test, then respond with "git bisect good" or "git bisect bad", > and keep going. > > The commit that "git bisect" finally finds and reports as the bad one is > not necessarily the current one; you have to read the diagnostic. I.e. if > the last commit to be tested is a "git bisect good", it will stay there and > report the bad one. > > > > > >
