All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guilherme Amadio <amadio@gentoo.org>
To: Ian Rogers <irogers@google.com>
Cc: acme@kernel.org, namhyung@kernel.org,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org
Subject: Re: Problem with perf report --gtk
Date: Tue, 9 Sep 2025 15:37:44 +0200	[thread overview]
Message-ID: <aMAtqNq55TZEuaKn@gentoo.org> (raw)
In-Reply-To: <CAP-5=fVA_Cduf9NvFAJezcNcg0JDNGa5q7m_mRBWNAYGEUo8bw@mail.gmail.com>

On Tue, Sep 09, 2025 at 06:04:42AM -0700, Ian Rogers wrote:
> On Tue, Sep 9, 2025 at 3:33 AM Guilherme Amadio <amadio@gentoo.org> wrote:
> >
> > Hi Arnaldo, Namhyung,
> >
> > Since sometime we have a bug in Gentoo's bugzilla about perf report --gtk not
> > working¹: https://bugs.gentoo.org/937869
> >
> > I know this feature is not used very much, but I thought I'd report in
> > any case. The problem is easily reproducible as shown below:
> >
> >
> > $ perf record -a -g -- sleep 1
> > [ perf record: Woken up 1 times to write data ]
> > [ perf record: Captured and wrote 1.818 MB perf.data (6648 samples) ]
> > $ LD_DEBUG=symbols perf report --gtk 2>&1 | grep '(fatal)'
> >     288067:     /usr/libexec/perf-core/libperf-gtk.so: error: symbol lookup error: undefined symbol: hashmap_find (fatal)
> > $ perf report --gtk
> > GTK browser requested but could not find libperf-gtk.so
> >
> > I tried this with perf 6.16, but this bug seems to have been there since
> > at least 6.12.
> >
> > Please let me know if it's better to file problems at https://bugzilla.kernel.org/.
> 
> Thanks for letting us know Guilherme! I suspect I broke things when
> trying to fix python things. The code linking libperf-gtk.so is:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/Makefile.perf?h=perf-tools-next#n809
> The hashmap symbols are part of the perf-util library:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/Build?h=perf-tools-next#n197
> So maybe there needs to be a libbpf -lbpf for your case? Alternatively
> we may need to reorder the libraries here:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/Makefile.perf?h=perf-tools-next#n464
> like:
> PERFLIBS += $(LIBPERF_BENCH) $(LIBPERF_TEST) $(LIBPERF_UI) $(LIBPERF_UTIL)
> becomes:
> PERFLIBS += $(LIBPERF_BENCH) $(LIBPERF_TEST) $(LIBPERF_UTIL) $(LIBPERF_UI)

Thank you for the suggestion, but just changing the order of linking or
linking libbpf doesn't seem to fix the issue. I still see:

$ nm -D libperf-gtk.so | grep hashmap
                 U hashmap_find

at the end of the build. The function is in util/hashmap.c, so the
problem might be more involved than just the linking order.

Best regards,
-Guilherme

  reply	other threads:[~2025-09-09 13:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-09 10:33 Problem with perf report --gtk Guilherme Amadio
2025-09-09 13:04 ` Ian Rogers
2025-09-09 13:37   ` Guilherme Amadio [this message]
2025-09-10 16:45     ` Ian Rogers
2025-09-12 11:49       ` Guilherme Amadio
2025-09-12 18:36         ` Ian Rogers

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=aMAtqNq55TZEuaKn@gentoo.org \
    --to=amadio@gentoo.org \
    --cc=acme@kernel.org \
    --cc=irogers@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=namhyung@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.