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. -Doug
