Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200131181123.tmamivhq4b7uqasr@gmail.com> <30752f2a-fe0b-4150-c32d-07690fb43b82@windriver.com>
In-Reply-To: <30752f2a-fe0b-4150-c32d-07690fb43b82@windriver.com>
From:   Sam Lunt <samueljlunt@gmail.com>
Date:   Sat, 22 Feb 2020 10:38:09 -0600
Message-ID: <CAGn10uUFJLh7J5rNcbH-Y6aGGr0vK_YN40gry9PXh_tx3sSXMg@mail.gmail.com>
Subject: Re: [PATCH] perf: Support Python 3.8+ in Makefile
To:     He Zhe <zhe.he@windriver.com>
Cc:     linux-kernel@vger.kernel.org, peterz@infradead.org,
        mingo@redhat.com, acme@kernel.org, mark.rutland@arm.com,
        alexander.shishkin@linux.intel.com, Jiri Olsa <jolsa@redhat.com>,
        namhyung@kernel.org, trivial@kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, Feb 16, 2020 at 8:24 PM He Zhe <zhe.he@windriver.com> wrote:
> On 2/1/20 2:11 AM, Sam Lunt wrote:
> > Python 3.8 changed the output of 'python-config --ldflags' to no longer
> > include the '-lpythonX.Y' flag (this apparently fixed an issue loading
> > modules with a statically linked Python executable).  The libpython
> > feature check in linux/build/feature fails if the Python library is not
> > included in FEATURE_CHECK_LDFLAGS-libpython variable.
> >
> > This adds a check in the Makefile to determine if PYTHON_CONFIG accepts
> > the '--embed' flag and passes that flag alongside '--ldflags' if so.
> >
> > tools/perf is the only place the libpython feature check is used.
> >
> > Signed-off-by: Sam Lunt <samuel.j.lunt@gmail.com>
> > ---
> >  tools/perf/Makefile.config | 11 ++++++++++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> > index c90f4146e5a2..ccf99351f058 100644
> > --- a/tools/perf/Makefile.config
> > +++ b/tools/perf/Makefile.config
> > @@ -228,8 +228,17 @@ strip-libs  = $(filter-out -l%,$(1))
> >
> >  PYTHON_CONFIG_SQ := $(call shell-sq,$(PYTHON_CONFIG))
> >
> > +# Python 3.8 changed the output of `python-config --ldflags` to not include the
> > +# '-lpythonX.Y' flag unless '--embed' is also passed. The feature check for
> > +# libpython fails if that flag is not included in LDFLAGS
> > +ifeq ($(shell $(PYTHON_CONFIG_SQ) --ldflags --embed 2>&1 1>/dev/null; echo $$?), 0)
> > +  PYTHON_CONFIG_LDFLAGS := --ldflags --embed
> > +else
> > +  PYTHON_CONFIG_LDFLAGS := --ldflags
> > +endif
> > +
> >  ifdef PYTHON_CONFIG
> > -  PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
> > +  PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) $(PYTHON_CONFIG_LDFLAGS) 2>/dev/null)
>
> I met the same problem. Would the following change be more simple and clear?
>
> -  PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
> +  PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) --ldflags --embed 2>/dev/null || $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)

That change is nearly equivalent to the change I'd suggested, just
squashed into one line. I think it's certainly more terse, but I'm not
sure it's any clearer.

It's also making the implicit assumption that PYTHON_CONFIG_SQ does
not print anything to stdout when it exits with a non-zero return
code. I think that's probably a safe assumption, but it seems more
robust not to make that assumption at all.

Best,
Sam