From: Nathan Chancellor <nathan@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nicolas Schier <nicolas@fjasle.eu>,
Borislav Petkov <bp@alien8.de>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>
Subject: Re: Tool directory build problem..
Date: Mon, 29 Sep 2025 13:25:12 -0500 [thread overview]
Message-ID: <20250929182512.GA1394437@ax162> (raw)
In-Reply-To: <CAHk-=wgYcmBXuE8OMoDF6vGwk9n_2XdwWbuh-5b0w0g7w-NK=g@mail.gmail.com>
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
next prev parent reply other threads:[~2025-09-29 18:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-27 18:23 Tool directory build problem Linus Torvalds
2025-09-27 20:18 ` Nicolas Schier
2025-09-29 18:25 ` Nathan Chancellor [this message]
2025-09-29 18:29 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250929182512.GA1394437@ax162 \
--to=nathan@kernel.org \
--cc=bp@alien8.de \
--cc=linux-kbuild@vger.kernel.org \
--cc=nicolas@fjasle.eu \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.