From: anzhou94 <anzhou94@gmail.com>
To: linux-perf-users@vger.kernel.org
Subject: Manually setting libbfd unavailable will cause perf building aborted
Date: Thu, 1 Apr 2021 14:06:09 +0800 [thread overview]
Message-ID: <5ec369cd-cd78-7dea-de75-6666711ccd19@gmail.com> (raw)
Hi, all
When buiiding perf, whether libbfd available and whether libbfd supports
buildid feature will be checked. The check results are stored in two
variables: feature-libbfd and feature-libbfd-buildid. Then the variables
will be used in tools/perf/Makefile.conf as follows:
ifeq ($(feature-libbfd), 1)
EXTLIBS += -lbfd -lopcodes
else
...
endif
ifeq ($(feature-libbfd-buildid), 1)
CFLAGS += -DHAVE_LIBBFD_BUILDID_SUPPORT
else
msg := $(warning Old version of libbfd/binutils things ... will not be
available);
endif
When compiling and executing the corresponding test program to get the
check results, the above codes works well. While, when manually setting
libbfd unavariable, i.e. feature-libbfd=0, these codes will cause
building perf aborted.
Why? That's because whether libbfd is available and whether libbfd
supports buildid are individually checked and used. When we manually
setting feature-libbfd=0, value of feature-libbfd-buildid could be 1. I
encountered such thing when building debian linux-image from source.
If libbfd unavailable, to check whether libbfd supports build is
meaningless. Hence, unless libbfd available, we shouldn't check whether
libbfd supports buildid. So, the above codes should be fixed:
ifeq ($(feature-libbfd), 1)
EXTLIBS += -lbfd -lopcodes
else
...
ifeq ($(feature-libbfd-buildid), 1)
CFLAGS += -DHAVE_LIBBFD_BUILDID_SUPPORT
else
msg := $(warning Old version of libbfd/binutils things ... will not
be available);
endif
endif
reply other threads:[~2021-04-01 6:09 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=5ec369cd-cd78-7dea-de75-6666711ccd19@gmail.com \
--to=anzhou94@gmail.com \
--cc=linux-perf-users@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).