Re: Tool directory build problem..

[Nicolas Schier <nsc@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3788 bytes --]

Hi Linus,

On Sat, Sep 27, 2025 at 11:23:22AM -0700, Linus Torvalds wrote:
> This isn't new, but I hit the problem once again because I decided
> that I should make sure to build-test the tools before the 6.17
> release since I got another tool pull fairly late in the game..
> 
> And it fails annoyingly and immediately, with
> 
>     make tools/all
> 
> failing quickly for the ACPI pfrut tool with
> 
>     undefined reference to `uuid_unparse'
> 
> errors.
> 
> Those errors do *not* happen if you build it inside the tools/
> directory itself. So doing
> 
>     make -C tools all
> 
> works just fine, but we literally have a "tools/%" target that is
> designed for this, and it doesn't work.
> 
> It doesn't work for that pfrut tool because the top-level Makefile
> rule does this:
> 
>     $(Q)$(MAKE) LDFLAGS= O=$(abspath $(objtree)) subdir=tools -C
> $(srctree)/tools/ $*
> 
> and that "LDFLAGS=" is an overriding variable assignment, so the use of
> 
>     LDFLAGS += -luuid
> 
> in tools/power/acpi/tools/pfrut/Makefile end sup not working.
> 
> But it works in all other situations, just not when build this way
> from the top. Annoying.
> 
> I'm not sure *why* the top-level Makefile does that "LDFLAGS="
> override thing. It doesn't do it for anything else. Just that LDFLAGS
> variable.
> 
> Yes, yes, the ACPI tool makefile could then use
> 
>     override LDFLAGS += -luuid
> 
> but why would it do something as crazy as that?
> 
> That "LDFLAGS=" override goes back many many years,  In fact, it goes
> back to the very initial addition of those rules in commit
> ea01fa9f63ae ("tools: Connect to the kernel build system").

I have never really dived into the tools/ tree, thus I am not able to give
helpful comment about build problems of any tools/% target,
spontaneously.


But I know that there has been a long-term strained relationship between
kbuild and tools.  Masahiro put it this way in June 2024, when asked
about his concerns about the tools/ integration in top-level Makefile:

Masahiro put this

    # The tools build system is not a part of Kbuild and tends to introduce
    # its own unique issues. If you need to integrate a new tool into Kbuild,
    # please consider locating that tool outside the tools/ tree and using the
    # standard Kbuild "hostprogs" syntax instead of adding a new tools/* entry
    # here. See Documentation/kbuild/makefiles.rst for details.

into top-level Makefile after yet another troublesome patch discussion
(referenced in commit 6e6ef2da3a28f3e02).


Further, he mentioned worries about the (current) situation:

    The tool build is integrated as a pattern rule in the top Makefile.
    (tools/%)

    So, you can build other tools from the top Makefile.

    See commit ea01fa9f63aef, which did not get Ack from any Kbuild
    maintainer, and caused subsequent troubles, and the benefit
    of which I still do not understand.
    
    Supporting "make tools/perf" in addition to "make -C tools perf"
    only saved a few characters to type.
    
    So, the problem remains, unless I revert ea01fa9f63aef.
    
    I decided to not care about it too much, as long as
    such tools are not used during the kernel build.
    
    I am really worried about objtool and resolve_btfids,
    as these two are used for building the kernel.

    https://lore.kernel.org/linux-kbuild/CAK7LNASZi3A_BzFACOvZhwByHaVon-Cd5H++uygsv4m_fhDOyQ@mail.gmail.com/

So, to be honest, I doubt we have someone at hand right now who is able
to fix the tools/ tree.

Personally, I'd favor if we could work towards removal of the 'tools/%'
rule in top-level Makefile, as long as tools/ is not kbuild-compliant.

Kind regards,
Nicolas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]