Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2404147pxb; Thu, 4 Nov 2021 20:23:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwkkBqD58xWfLo9j6qlvW9T7hbTKiQEVwn/v/1hqXF+0WIK0W34j+K6bk84PVSjbMgnO40s X-Received: by 2002:a17:906:26ce:: with SMTP id u14mr70563118ejc.559.1636082618016; Thu, 04 Nov 2021 20:23:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1636082618; cv=none; d=google.com; s=arc-20160816; b=M7oCzIsfJkqEg2Rrf29sOpSmgCJorGWBsfBOGXmvpKE5zcVshaqYDDvQc7k3ZCv8Yj X0syy16/N05DmKaiQmjgkcWmJ5p3SdSFxoo4rLctiv3qxHMFmbLJP6sDg2n/kzpSyYzi ua4Nyu329zkezhnHUSDdlVJrsChPmw3HaeedQZS3a9Rel+0VSpvYF5OicPDtOjr8dqNM eXDeXjlSEbXVy1VgaZZvkNfoQfS9B/4wz4uDwBesMOT8ufCpuGAfZ8aNtDUNyThqiMVj O8nPd0X42PfoL+/to+A/Jiozuk4olj4Rd0HVRJ/c/iY3tGQE+i2LvbESZX1ePeDmtYGq zxXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=A/kLks/zJAbqNPgvU1IYi+YJZ7HhxQeyO1xLENQvTFw=; b=hbX1th6jwqkpMAtTdiq3WtiBnwl7GokPl/retfQbDqKUWcdSy9JgEFjV2JZI0uJRYy KdGORIIaRossmpZopdZ3gfKjKtZ6rWYu7mKtkrYOQlcSNWfNNEZZu8v2DbBsadU5yXrl UpnN8Bzj7C4I3GYTMQ5UqFTihaW4KWhi7nbLyP0jJeU42Bs6rUf3+eil5MpEj+BNU7/x bLr17+fKLeuC5BuXCK8p80yOTutH/3H7L8dk0jlQvN5+fsaLuHllbpdEe+s7aUcc/qvK 1OfEu6qMauqy3AkNvRRG6vLraw7p7b8cCqIMQkQcfX2ehQg9WxMclJAWnEBUqFXl+fsV z9Kg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@isovalent-com.20210112.gappssmtp.com header.s=20210112 header.b=I4IRDfeH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id he37si10485634ejc.529.2021.11.04.20.23.13; Thu, 04 Nov 2021 20:23:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@isovalent-com.20210112.gappssmtp.com header.s=20210112 header.b=I4IRDfeH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231543AbhKECG1 (ORCPT + 99 others); Thu, 4 Nov 2021 22:06:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230227AbhKECG0 (ORCPT ); Thu, 4 Nov 2021 22:06:26 -0400 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1F22C061203 for ; Thu, 4 Nov 2021 19:03:47 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id 67-20020a1c1946000000b0030d4c90fa87so5521999wmz.2 for ; Thu, 04 Nov 2021 19:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isovalent-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=A/kLks/zJAbqNPgvU1IYi+YJZ7HhxQeyO1xLENQvTFw=; b=I4IRDfeHNWXFdDBFFpPOltZGn1XiGF84YxQxMEp1KA79xbM2TGPxiRPBAIL2fT8MFO LVvLPgr7Ho56e8r6ZnRrvSIo1VCLTRqIkBe69dmynQ+nQxLH6tGwzPorbfFe8+Lhgkqu z3U0TH+T0+dYsuA/jFc+Fp5NZ7SZWSRsqXisErH3fOEpAVd5AB3o1WuHvzAHijWkv7cp N4rBj3LB9QG0ccw6+pGjiHVWQ5/DiS6cy4Fws4fo4hWyq+OpUDzu5KWuVEgxqVVjYcUu uT4ahy1gROrnUc5qHJjfyRThS1K2gEaMWhsHRk0mnx/GayEa+a7ZTzvLM0XpcTzeEDPe +RLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=A/kLks/zJAbqNPgvU1IYi+YJZ7HhxQeyO1xLENQvTFw=; b=CPuM4NuncHMAu2DrkCCPujeGpawfHEuTDRkmkSLwsm9ppbej8gK4vFd4PpfQ/+Zdxm rM7L7jwxuSid8zFCkPiywKrsVp7wQoxKq3nR40LqzfuagNV/GOYMmBJwEA6++JiNNU2u rwSk0E3hNhJwSQeAo2f1uaRamhd8fCSowzIOGW6pPbbNTwKAj5s4+UJ6o5jUp2JREejN gR4f8HJ0uaYjza88qFdK4KRdTI2HiYCUMZ2arPviZ04LuCnnc0e0SHtWuOax4AleK4RU TPXZGtJx/NZBpSf7hbBZe/DzGJi70LO0Oa/P6S4kCN5D3z1amG7vEZcZmGW2wCFIuPro 1ltQ== X-Gm-Message-State: AOAM532NARamBFNW7hCvC60YR5wpK3/BjW/0heRnokyLVf3YG9RkueXi yuvsR3ZKW7nVChsScV89CLg7yA== X-Received: by 2002:a1c:750b:: with SMTP id o11mr27809906wmc.5.1636077826180; Thu, 04 Nov 2021 19:03:46 -0700 (PDT) Received: from [192.168.1.11] ([149.86.70.55]) by smtp.gmail.com with ESMTPSA id c79sm6820714wme.43.2021.11.04.19.03.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Nov 2021 19:03:45 -0700 (PDT) Message-ID: <85136cd4-edb1-ff6f-5379-f64db5caae5d@isovalent.com> Date: Fri, 5 Nov 2021 02:03:45 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: perf build broken looking for bpf/{libbpf,bpf}.h after merge with upstream Content-Language: en-GB To: Arnaldo Carvalho de Melo Cc: Andrii Nakryiko , Song Liu , Jiri Olsa , Namhyung Kim , bpf , Linux Kernel Mailing List References: <83f48296-fa72-a27f-5acb-654b51cd848f@isovalent.com> From: Quentin Monnet In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2021-11-04 17:45 UTC-0300 ~ Arnaldo Carvalho de Melo > Em Thu, Nov 04, 2021 at 05:15:20PM -0300, Arnaldo Carvalho de Melo escreveu: >> Em Thu, Nov 04, 2021 at 06:15:57PM +0000, Quentin Monnet escreveu: >>> 2021-11-04 15:09 UTC-0300 ~ Arnaldo Carvalho de Melo >>>> Em Thu, Nov 04, 2021 at 10:47:12AM -0700, Andrii Nakryiko escreveu: >>>>> On Thu, Nov 4, 2021 at 10:38 AM Arnaldo Carvalho de Melo wrote: >>>>> cc Quentin as well, might be related to recent Makefiles revamp for >>>>> users of libbpf. But in bpf-next perf builds perfectly fine, so not >>>>> sure. > >>>> This did the trick: > >>>> ⬢[acme@toolbox perf]$ git show >>>> commit 504afe6757ec646539ca3b4aa0431820e8c92b45 (HEAD -> perf/core) >>>> Author: Arnaldo Carvalho de Melo >>>> Date: Thu Nov 4 14:58:56 2021 -0300 > >>>> Revert "bpftool: Remove Makefile dep. on $(LIBBPF) for $(LIBBPF_INTERNAL_HDRS)" > >>>> This reverts commit 8b6c46241c774c83998092a4eafe40f054568881. > >>>> Signed-off-by: Arnaldo Carvalho de Melo > >>>> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile >>>> index c0c30e56988f2cbe..c5ad996ee95d4e87 100644 >>>> --- a/tools/bpf/bpftool/Makefile >>>> +++ b/tools/bpf/bpftool/Makefile >>>> @@ -39,14 +39,14 @@ ifeq ($(BPFTOOL_VERSION),) >>>> BPFTOOL_VERSION := $(shell make -rR --no-print-directory -sC ../../.. kernelversion) >>>> endif > >>>> -$(LIBBPF_OUTPUT) $(BOOTSTRAP_OUTPUT) $(LIBBPF_BOOTSTRAP_OUTPUT) $(LIBBPF_HDRS_DIR): >>>> +$(LIBBPF_OUTPUT) $(BOOTSTRAP_OUTPUT) $(LIBBPF_BOOTSTRAP_OUTPUT): >>>> $(QUIET_MKDIR)mkdir -p $@ > >>>> $(LIBBPF): $(wildcard $(BPF_DIR)/*.[ch] $(BPF_DIR)/Makefile) | $(LIBBPF_OUTPUT) >>>> $(Q)$(MAKE) -C $(BPF_DIR) OUTPUT=$(LIBBPF_OUTPUT) \ >>>> DESTDIR=$(LIBBPF_DESTDIR) prefix= $(LIBBPF) install_headers > >>>> -$(LIBBPF_INTERNAL_HDRS): $(LIBBPF_HDRS_DIR)/%.h: $(BPF_DIR)/%.h | $(LIBBPF_HDRS_DIR) >>>> +$(LIBBPF_INTERNAL_HDRS): $(LIBBPF_HDRS_DIR)/%.h: $(BPF_DIR)/%.h $(LIBBPF) >>>> $(call QUIET_INSTALL, $@) >>>> $(Q)install -m 644 -t $(LIBBPF_HDRS_DIR) $< > >>> Interesting. I needed that patch because otherwise I'd get errors when >>> compiling bpftool after the switch to libbpf's hashmap implementation. >>> For the current breakage, it could be a matter of how we pass variables >>> when descending into bpftool/ from perf's Makefile.perf. I'll try to >>> look at this in details, and to experiment tonight, if I can. (Thanks >>> Andrii for the CC!) > >> yeah, if we pass the location for those headers from the perf side, it >> should work. > > But it isn't obvious how perf should communicate to bpftool where to > find bpf/bpf.h for the bootstrap make target, which seems something > bpftool should know. > > Anyway, I'm calling it a day, will get back to this tomorrow, if you > don't beat me to it. Found it. The issue is on bpftool's side. Background context: I've recently changed the way that bpftool (and other tools) include libbpf's headers: now they "install" the API headers locally, instead of including them directly from libbpf's source directory. Looks like I forgot perf's Makefile in the process by the way, I've sent a patch to address this (but this is not the cause of the breakage). For bpftool, we need to build two versions of libbpf, the bootstrap version (for bootstrap bpftool) and the "regular" one. But I made the Makefile export the API headers from libbpf only once, for the "regular" build, and not for the bootstrap build. For bpftool it doesn't matter, because the bootstrap bpftool build always occurs after libbpf has been built and its headers have been exported. For other tools relying on bootstrap bpftool only, like perf, this means that the libbpf headers are not installed. For some time, the build was still working, because the regular build for libbpf (with its export of the headers) was passed as a dependency to another step required by the bootstrap bpftool, such that the headers were (involuntarily) installed for bootstrap bpftool. This was changed in commit 8b6c46241c77, the one that you proposed to revert. That commit removes the dependency on the "regular" libbpf build for the bootstrap bpftool. It's cleaner, but it breaks the build for tools that just need boostrap bpftool. Anyway. I just sent a fix, in which I propose to also install libbpf's headers for the bootstrap build. Quentin