On Wed, Mar 19, 2025 at 1:41 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > Hi, > > On Mon, Feb 10, 2025 at 4:30 PM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > > > > When CONFIG_OBJTOOL=y or CONFIG_DEBUG_INFO_BTF=y, parallel builds > > show awkward "mkdir -p ..." logs. > > > > $ make -j16 > > [ snip ] > > mkdir -p /home/masahiro/ref/linux/tools/objtool && make O=/home/masahiro/ref/linux subdir=tools/objtool --no-print-directory -C objtool > > mkdir -p /home/masahiro/ref/linux/tools/bpf/resolve_btfids && make O=/home/masahiro/ref/linux subdir=tools/bpf/resolve_btfids --no-print-directory -C bpf/resolve_btfids > > > > Defining MAKEFLAGS=<value> on the command line wipes out command line > > switches from the resultant MAKEFLAGS definition, even though the command > > line switches are active. [1] > > > > The first word of $(MAKEFLAGS) is a possibly empty group of characters > > representing single-letter options that take no argument. However, this > > breaks if MAKEFLAGS=<value> is given on the command line. > > > > The tools/ and tools/% targets set MAKEFLAGS=<value> on the command > > line, which breaks the following code in tools/scripts/Makefile.include: > > > > short-opts := $(firstword -$(MAKEFLAGS)) > > > > If MAKEFLAGS really needs modification, it should be done through the > > environment variable, as follows: > > > > MAKEFLAGS=<value> $(MAKE) ... > > > > That said, I question whether modifying MAKEFLAGS is necessary here. > > The only flag we might want to exclude is --no-print-directory, as the > > tools build system changes the working directory. However, people might > > find the "Entering/Leaving directory" logs annoying. > > > > I simply removed the offending MAKEFLAGS=. > > > > [1]: https://savannah.gnu.org/bugs/?62469 > > > > Fixes: a50e43332756 ("perf tools: Honor parallel jobs") > > Signed-off-by: Masahiro Yamada <masahiroy@xxxxxxxxxx> > > --- > > > > Makefile | 9 ++------- > > 1 file changed, 2 insertions(+), 7 deletions(-) > > I happened to sync up to mainline today and noticed that my build was > broken. I bisected it to this change and reverting this change fixes > my build on mainline. > > In my case I'm building in a ChromeOS environment and using clang as > my compiler. I'm also cross-compiling an arm64 kernel on x86 host. > ...but the pure mainline kernel should work there. Presumably the > environment is a bit different compared to the typical one, though? > > The error comes up when doing a clean build and the first error messages are: > > In file included from libbpf.c:36: > .../tools/include/uapi/linux/bpf_perf_event.h:14:21: error: field has > incomplete type > 'bpf_user_pt_regs_t' (aka 'struct user_pt_regs') > 14 | bpf_user_pt_regs_t regs; > | ^ > .../tools/include/../../arch/arm64/include/uapi/asm/bpf_perf_event.h:7:16: > note: forward > declaration of 'struct user_pt_regs' > 7 | typedef struct user_pt_regs bpf_user_pt_regs_t; > | ^ > > btf_dump.c:1860:10: error: cast to smaller integer type 'uintptr_t' > (aka 'unsigned int') from 'const void *' > [-Werror,-Wvoid-pointer-to-int-cast] > 1860 | return ((uintptr_t)data) % alignment == 0; > | ^~~~~~~~~~~~~~~ > btf_dump.c:2045:4: error: format specifies type 'ssize_t' (aka 'long') > but the argument has type 'ssize_t' (aka 'int') > [-Werror,-Wformat] > 2044 | pr_warn("unexpected elem size %zd for array > type [%u]\n", > | ~~~ > | %d > 2045 | (ssize_t)elem_size, id); > | ^~~~~~~~~~~~~~~~~~ > ./libbpf_internal.h:171:52: note: expanded from macro 'pr_warn' > 171 | #define pr_warn(fmt, ...) __pr(LIBBPF_WARN, fmt, ##__VA_ARGS__) > | ~~~ ^~~~~~~~~~~ > > > I don't have time to dig right now, but I figured I'd at least post in > case the problem is obvious to someone else. I do not understand how to reproduce this. Your build machine is Chrome OS, or other distributions? Did you build the upstream kernel or downstream one? What is the build command? Just "make" ? -- Best Regards Masahiro Yamada
