Re: Make 4.3 rebuilds .o files when unnecessary

[Tommaso Fonda]

Hello, I have got some news. The issue was not introduced in make 4.3, but
it was introduced some time between make 4.2.1 and make 4.2.90.
I ran make 4.3 with the --trace option, the result I saw was, for example
(I have translated the string from Italian to English, thus the message is
probably not 100% equal to the native English one):
scripts/Makefile.build:307: updating target «arch/arm/mm/iomap.o» because
of: FORCE include/generated/bounds.h

The header written after "FORCE" was sometimes different.

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,
--
Tommaso Fonda

Il giorno ven 20 nov 2020 alle ore 17:40 Kaz Kylheku (gmake) <
729-670-0061@kylheku.com> ha scritto:

> On 2020-11-19 23:58, Tommaso Fonda wrote:
>
> The kernel tree I'm working on is much, much older than yours (it's Linux
> 3.4!)...
> Given it's not a make-related problem, I guess it's a problem with Linux
> 3.4's general Makefile & build system. I'll have to stick to make 4.2,
> however I'll try to build newer kernel trees (for x86_64, but it shouldn't
> make any difference) to find which is the oldest in which I cannot
> reproduce this issue. If I find the root cause of the problem, I might be
> able to "backport" the fix from said kernel version into my 3.4 tree.
> If you have any additional suggestions, do let me know, please!
> Thank you to both of you for your help.
>
>
> Here is one idea.
>
> Since you have the one variable that reliably triggers repro (varying make
> between 4.2 and 4.3) one thing to try would be to build make from the git
> repository, and use "git bisect" to see if this can be narrowed down to a
> particular commit between 4.2 and 4.3.
>
> (Building make from the git repo is a little different from using the
> official tarball, because the autoconf materials in the tarball have
> already been boostrapped. I think that, like for many other GNU programs,
> you have to run "make boostrap", which will require a few tools to be
> installed that the distribution tarball doesn't.)
>
> Anyway, if it is traced to a particular commit, that will likely reveal
> which feature(s) of gmake are involved, which will help to determine what
> to look for, or where to look, in the affected build system.
>
>