Tool directory build problem..

Tool directory build problem..

[Linus Torvalds]

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").

So I have no idea why it exists. Just removing the "LDFLAGS=" override
seems to fix everything for me, but I must be missing something.

And when I say "fix everything", I lie. It fixes this issue, and most
things build find, but it eventually ends up hitting a few build
errors in the tests and then fatally for virtio_test.

That seems to be entirely unrelated, and an actual real build problem
(possibly me not having some library or other, my motivation to look
into it ran out).

Comments?

              Linus

Re: Tool directory build problem..

[Nicolas Schier]

[-- 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 --]

Re: Tool directory build problem..

[Nathan Chancellor]

Hi Linus,

On Sat, Sep 27, 2025 at 11:23:22AM -0700, Linus Torvalds wrote:
> 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").
> 
> So I have no idea why it exists. Just removing the "LDFLAGS=" override
> seems to fix everything for me, but I must be missing something.

It looks like prior to commit d503ac531a52 ("kbuild: rename LDFLAGS to
KBUILD_LDFLAGS") in 4.19, LDFLAGS was used throughout Kbuild so I
suspect that LDFLAGS= was there to avoid poluting the tools build with
the flags from the main kernel build. Given the rename, it seems like
you should be able to remove LDFLAGS= from the tools target without any
problems.

I generally agree with Masahiro's prior comments around the tools/ build
system (especially hooking into it for the main kernel build) but I do
not see a good reason to break the tools/% target patterns if they are
not overly broken or hard to maintain :)

Cheers,
Nathan

Re: Tool directory build problem..

[Linus Torvalds]

On Mon, 29 Sept 2025 at 11:25, Nathan Chancellor <nathan@kernel.org> wrote:
>
> It looks like prior to commit d503ac531a52 ("kbuild: rename LDFLAGS to
> KBUILD_LDFLAGS") in 4.19, LDFLAGS was used throughout Kbuild so I
> suspect that LDFLAGS= was there to avoid poluting the tools build with
> the flags from the main kernel build. Given the rename, it seems like
> you should be able to remove LDFLAGS= from the tools target without any
> problems.

Sounds good.  I'll do just that.

> I generally agree with Masahiro's prior comments around the tools/ build
> system (especially hooking into it for the main kernel build) but I do
> not see a good reason to break the tools/% target patterns if they are
> not overly broken or hard to maintain :)

Yeah, we can remove it later if it causes more problems, but it does
sound like it was just a workaround for a kernel build system issue
that no longer exists.

Not that the "make -C tools" pattern is all that complex, but it's
different from all the normal kernel build patterns so I find the
whole "make tools/all" syntax more natural...

                Linus