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) < [email protected]> 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. > >
