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.
