From: Michael Petlan <mpetlan@redhat.com>
To: irogers@google.com, linux-perf-users@vger.kernel.org
Cc: acme@redhat.com, vmolnaro@redhat.com, jplesnik@redhat.com
Subject: python3-perf pulling dependencies after build refactoring
Date: Mon, 4 Nov 2024 22:21:57 +0100 (CET) [thread overview]
Message-ID: <fafa202f-59a-4838-1e30-74b4862aed5@redhat.com> (raw)
Hello Ian,
Jitka Plesnikova has spotted an interesting fact about he python bindings --
perf.cpython-*-x86_64-linux-gnu.so library -- the number of shared objects it
links against has significantly grown between v6.10 and v6.11:
Before:
# ldd python/perf.cpython-39-x86_64-linux-gnu.so
linux-vdso.so.1 (0x00007ffefd1cb000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4c9315e000)
libz.so.1 => /lib64/libz.so.1 (0x00007f4c93144000)
libelf.so.1 => /lib64/libelf.so.1 (0x00007f4c929e4000)
libslang.so.2 => /lib64/libslang.so.2 (0x00007f4c92600000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4c92200000)
libnuma.so.1 => /lib64/libnuma.so.1 (0x00007f4c93136000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4c93247000)
libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f4c9290d000)
After:
# ldd python/perf.cpython-39-x86_64-linux-gnu.so
linux-vdso.so.1 (0x00007ffd889f3000)
libm.so.6 => /lib64/libm.so.6 (0x00007f75cd125000)
libz.so.1 => /lib64/libz.so.1 (0x00007f75cdbc0000)
libelf.so.1 => /lib64/libelf.so.1 (0x00007f75cdba4000)
libdw.so.1 => /lib64/libdw.so.1 (0x00007f75cd089000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f75ccc00000)
libslang.so.2 => /lib64/libslang.so.2 (0x00007f75cc800000)
libperl.so.5.32 => /lib64/libperl.so.5.32 (0x00007f75cc400000)
libc.so.6 => /lib64/libc.so.6 (0x00007f75cc000000)
libpython3.9.so.1.0 => /lib64/libpython3.9.so.1.0 (0x00007f75cbc00000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f75cb800000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f75cdb76000)
libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f75ccb29000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f75cdb6a000)
libnuma.so.1 => /lib64/libnuma.so.1 (0x00007f75cdb5c000)
libbabeltrace-ctf.so.1 => /lib64/libbabeltrace-ctf.so.1 (0x00007f75cd03f000)
libpfm.so.4 => /lib64/libpfm.so.4 (0x00007f75cb400000)
libtraceevent.so.1 => /lib64/libtraceevent.so.1 (0x00007f75ccb08000)
/lib64/ld-linux-x86-64.so.2 (0x00007f75cdbe8000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f75cdb49000)
libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f75cc7c6000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f75ccaed000)
libbabeltrace.so.1 => /lib64/libbabeltrace.so.1 (0x00007f75ccadd000)
libpopt.so.0 => /lib64/libpopt.so.0 (0x00007f75cc7b7000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f75cdb3d000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f75cd039000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f75cc2c5000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f75cc24d000)
I have narrowed it down to e467705a9fb3 ("perf util: Make util its own library").
It has also grown in size, probably because of this linking change. I think we
need to get rid of this probably unwanted side-effect of the build optimization.
What do you think?
Regards,
Michael
next reply other threads:[~2024-11-04 21:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-04 21:21 Michael Petlan [this message]
2024-11-04 21:57 ` python3-perf pulling dependencies after build refactoring 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=fafa202f-59a-4838-1e30-74b4862aed5@redhat.com \
--to=mpetlan@redhat.com \
--cc=acme@redhat.com \
--cc=irogers@google.com \
--cc=jplesnik@redhat.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=vmolnaro@redhat.com \
/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).