From: Andi Kleen <[email protected]>
The symbol the feature file checks for is now actually in -lbabeltrace,
not -lbabeltrace-ctf, at least as of libbabeltrace-1.5.6-2.fc30.x86_64
Always add both libraries to fix the feature detection.
Signed-off-by: Andi Kleen <[email protected]>
---
tools/perf/Makefile.config | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index bf8caa7d17f6..71638917e18a 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -155,7 +155,7 @@ ifdef LIBBABELTRACE_DIR
LIBBABELTRACE_LDFLAGS := -L$(LIBBABELTRACE_DIR)/lib
endif
FEATURE_CHECK_CFLAGS-libbabeltrace := $(LIBBABELTRACE_CFLAGS)
-FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) -lbabeltrace-ctf
+FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) -lbabeltrace-ctf -lbabeltrace
ifdef LIBZSTD_DIR
LIBZSTD_CFLAGS := -I$(LIBZSTD_DIR)/lib
@@ -895,7 +895,7 @@ ifndef NO_LIBBABELTRACE
ifeq ($(feature-libbabeltrace), 1)
CFLAGS += -DHAVE_LIBBABELTRACE_SUPPORT $(LIBBABELTRACE_CFLAGS)
LDFLAGS += $(LIBBABELTRACE_LDFLAGS)
- EXTLIBS += -lbabeltrace-ctf
+ EXTLIBS += -lbabeltrace-ctf -lbabeltrace
$(call detected,CONFIG_LIBBABELTRACE)
else
msg := $(warning No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev);
--
2.21.0
On Mon, Oct 07, 2019 at 10:41:20AM -0700, Andi Kleen wrote:
> From: Andi Kleen <[email protected]>
>
> The symbol the feature file checks for is now actually in -lbabeltrace,
> not -lbabeltrace-ctf, at least as of libbabeltrace-1.5.6-2.fc30.x86_64
>
> Always add both libraries to fix the feature detection.
well, we link with libbabeltrace-ctf.so which links with libbabeltrace.so
I guess we can link it as well, but where do you see it fail?
jirka
>
> Signed-off-by: Andi Kleen <[email protected]>
> ---
> tools/perf/Makefile.config | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index bf8caa7d17f6..71638917e18a 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -155,7 +155,7 @@ ifdef LIBBABELTRACE_DIR
> LIBBABELTRACE_LDFLAGS := -L$(LIBBABELTRACE_DIR)/lib
> endif
> FEATURE_CHECK_CFLAGS-libbabeltrace := $(LIBBABELTRACE_CFLAGS)
> -FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) -lbabeltrace-ctf
> +FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) -lbabeltrace-ctf -lbabeltrace
>
> ifdef LIBZSTD_DIR
> LIBZSTD_CFLAGS := -I$(LIBZSTD_DIR)/lib
> @@ -895,7 +895,7 @@ ifndef NO_LIBBABELTRACE
> ifeq ($(feature-libbabeltrace), 1)
> CFLAGS += -DHAVE_LIBBABELTRACE_SUPPORT $(LIBBABELTRACE_CFLAGS)
> LDFLAGS += $(LIBBABELTRACE_LDFLAGS)
> - EXTLIBS += -lbabeltrace-ctf
> + EXTLIBS += -lbabeltrace-ctf -lbabeltrace
> $(call detected,CONFIG_LIBBABELTRACE)
> else
> msg := $(warning No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev);
> --
> 2.21.0
>
On Tue, Oct 08, 2019 at 01:52:40PM +0200, Jiri Olsa wrote:
> On Mon, Oct 07, 2019 at 10:41:20AM -0700, Andi Kleen wrote:
> > From: Andi Kleen <[email protected]>
> >
> > The symbol the feature file checks for is now actually in -lbabeltrace,
> > not -lbabeltrace-ctf, at least as of libbabeltrace-1.5.6-2.fc30.x86_64
> >
> > Always add both libraries to fix the feature detection.
>
> well, we link with libbabeltrace-ctf.so which links with libbabeltrace.so
>
> I guess we can link it as well, but where do you see it fail?
On FC30 the .so file is just a symlink, so it doesn't pull
in the other library.
$ gcc test-libbabeltrace.c -lbabeltrace-ctf
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libbabeltrace-ctf.so:
undefined reference to `bt_packet_seek_get_error'
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libbabeltrace-ctf.so:
undefined reference to `bt_packet_seek_set_error'
collect2: error: ld returned 1 exit status
$ ls -l /usr/lib64/libbabeltrace-ctf.so
lrwxrwxrwx 1 root root 26 Jan 31 2019 /usr/lib64/libbabeltrace-ctf.so
-> libbabeltrace-ctf.so.1.0.0
$ rpm -qf /usr/lib64/libbabeltrace-ctf.so
libbabeltrace-devel-1.5.6-2.fc30.x86_64
-Andi
On Tue, Oct 08, 2019 at 07:21:44AM -0700, Andi Kleen wrote:
> On Tue, Oct 08, 2019 at 01:52:40PM +0200, Jiri Olsa wrote:
> > On Mon, Oct 07, 2019 at 10:41:20AM -0700, Andi Kleen wrote:
> > > From: Andi Kleen <[email protected]>
> > >
> > > The symbol the feature file checks for is now actually in -lbabeltrace,
> > > not -lbabeltrace-ctf, at least as of libbabeltrace-1.5.6-2.fc30.x86_64
> > >
> > > Always add both libraries to fix the feature detection.
> >
> > well, we link with libbabeltrace-ctf.so which links with libbabeltrace.so
> >
> > I guess we can link it as well, but where do you see it fail?
>
> On FC30 the .so file is just a symlink, so it doesn't pull
> in the other library.
>
> $ gcc test-libbabeltrace.c -lbabeltrace-ctf
> /usr/bin/ld:
> /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libbabeltrace-ctf.so:
> undefined reference to `bt_packet_seek_get_error'
> /usr/bin/ld:
> /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libbabeltrace-ctf.so:
> undefined reference to `bt_packet_seek_set_error'
> collect2: error: ld returned 1 exit status
I'm confused,
the test-libbabeltrace.c checks for bt_ctf_stream_class_get_packet_context_type
which is in libbabeltrace-ctf:
[jolsa@dell-r440-01 feature]$ nm -D /usr/lib64/libbabeltrace-ctf.so | grep bt_ctf_stream_class_get_packet_context_type
0000000000032960 T bt_ctf_stream_class_get_packet_context_type
[jolsa@dell-r440-01 feature]$ cat /etc/redhat-release
Fedora release 30 (Thirty)
[jolsa@dell-r440-01 feature]$ rpm -qa | grep libbabeltrace-1.5.6-2.fc30.x86_64
libbabeltrace-1.5.6-2.fc30.x86_64
I also get proper feature detection on F30:
$ make VF=1
... libbabeltrace: [ on ]
jirka
>
> $ ls -l /usr/lib64/libbabeltrace-ctf.so
> lrwxrwxrwx 1 root root 26 Jan 31 2019 /usr/lib64/libbabeltrace-ctf.so
> -> libbabeltrace-ctf.so.1.0.0
>
> $ rpm -qf /usr/lib64/libbabeltrace-ctf.so
> libbabeltrace-devel-1.5.6-2.fc30.x86_64
>
> -Andi
On Fri, Oct 11, 2019 at 04:05:48PM +0200, Jiri Olsa wrote:
> On Tue, Oct 08, 2019 at 07:21:44AM -0700, Andi Kleen wrote:
> > On Tue, Oct 08, 2019 at 01:52:40PM +0200, Jiri Olsa wrote:
> > > On Mon, Oct 07, 2019 at 10:41:20AM -0700, Andi Kleen wrote:
> > > > From: Andi Kleen <[email protected]>
> > > >
> > > > The symbol the feature file checks for is now actually in -lbabeltrace,
> > > > not -lbabeltrace-ctf, at least as of libbabeltrace-1.5.6-2.fc30.x86_64
> > > >
> > > > Always add both libraries to fix the feature detection.
> > >
> > > well, we link with libbabeltrace-ctf.so which links with libbabeltrace.so
> > >
> > > I guess we can link it as well, but where do you see it fail?
> >
> > On FC30 the .so file is just a symlink, so it doesn't pull
> > in the other library.
> >
> > $ gcc test-libbabeltrace.c -lbabeltrace-ctf
> > /usr/bin/ld:
> > /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libbabeltrace-ctf.so:
> > undefined reference to `bt_packet_seek_get_error'
> > /usr/bin/ld:
> > /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libbabeltrace-ctf.so:
> > undefined reference to `bt_packet_seek_set_error'
> > collect2: error: ld returned 1 exit status
>
> I'm confused,
> the test-libbabeltrace.c checks for bt_ctf_stream_class_get_packet_context_type
> which is in libbabeltrace-ctf:
AFAIK libbabeltrace-ctf uses these symbols from the object containing
bt_ctf_stream_class_get_packet_context_type
I assume you have FC30 so you should be able to reproduce it
-Andi
Em Tue, Oct 08, 2019 at 07:21:44AM -0700, Andi Kleen escreveu:
> On Tue, Oct 08, 2019 at 01:52:40PM +0200, Jiri Olsa wrote:
> > On Mon, Oct 07, 2019 at 10:41:20AM -0700, Andi Kleen wrote:
> > > From: Andi Kleen <[email protected]>
> > >
> > > The symbol the feature file checks for is now actually in -lbabeltrace,
> > > not -lbabeltrace-ctf, at least as of libbabeltrace-1.5.6-2.fc30.x86_64
> > >
> > > Always add both libraries to fix the feature detection.
> >
> > well, we link with libbabeltrace-ctf.so which links with libbabeltrace.so
> >
> > I guess we can link it as well, but where do you see it fail?
>
> On FC30 the .so file is just a symlink, so it doesn't pull
> in the other library.
>
> $ gcc test-libbabeltrace.c -lbabeltrace-ctf
> /usr/bin/ld:
> /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libbabeltrace-ctf.so:
> undefined reference to `bt_packet_seek_get_error'
> /usr/bin/ld:
> /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libbabeltrace-ctf.so:
> undefined reference to `bt_packet_seek_set_error'
> collect2: error: ld returned 1 exit status
>
> $ ls -l /usr/lib64/libbabeltrace-ctf.so
> lrwxrwxrwx 1 root root 26 Jan 31 2019 /usr/lib64/libbabeltrace-ctf.so
> -> libbabeltrace-ctf.so.1.0.0
>
> $ rpm -qf /usr/lib64/libbabeltrace-ctf.so
> libbabeltrace-devel-1.5.6-2.fc30.x86_64
I'm not being able to reproduce here, without your patch I get things
working:
[acme@quaco perf]$ ldd ~/bin/perf | grep babel
libbabeltrace-ctf.so.1 => /lib64/libbabeltrace-ctf.so.1 (0x00007f2396e41000)
libbabeltrace.so.1 => /lib64/libbabeltrace.so.1 (0x00007f2396dc1000)
[acme@quaco perf]$ ldd /lib64/libbabeltrace-ctf.so.1 | grep babel
libbabeltrace.so.1 => /lib64/libbabeltrace.so.1 (0x00007f8bffe59000)
[acme@quaco perf]$
[acme@quaco perf]$ rpm -qa | grep babeltrace
libbabeltrace-1.5.6-2.fc30.x86_64
libbabeltrace-devel-1.5.6-2.fc30.x86_64
[acme@quaco perf]$ cat /etc/fedora-release
Fedora release 30 (Thirty)
[acme@quaco perf]$ cat /tmp/build/perf/feature/test-libbabeltrace.make.output
[acme@quaco perf]$ cat /tmp/build/perf/feature/test-libbabeltrace.
test-libbabeltrace.bin test-libbabeltrace.d test-libbabeltrace.make.output
[acme@quaco perf]$ ldd /tmp/build/perf/feature/test-libbabeltrace.bin
linux-vdso.so.1 (0x00007fff5ff7c000)
libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8 (0x00007f2517979000)
libunwind.so.8 => /lib64/libunwind.so.8 (0x00007f251795f000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f2517936000)
libbabeltrace-ctf.so.1 => /lib64/libbabeltrace-ctf.so.1 (0x00007f25178e0000)
libc.so.6 => /lib64/libc.so.6 (0x00007f251771a000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2517700000)
/lib64/ld-linux-x86-64.so.2 (0x00007f25179bc000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f25176dd000)
libbabeltrace.so.1 => /lib64/libbabeltrace.so.1 (0x00007f25176cd000)
libdw.so.1 => /lib64/libdw.so.1 (0x00007f2517678000)
libelf.so.1 => /lib64/libelf.so.1 (0x00007f251765d000)
libpopt.so.0 => /lib64/libpopt.so.0 (0x00007f251764f000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f2517645000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f251763d000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f2517519000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2517513000)
libz.so.1 => /lib64/libz.so.1 (0x00007f25174f9000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f25174e5000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f251746f000)
[acme@quaco perf]$
> I'm not being able to reproduce here, without your patch I get things
> working:
Okay, looks like I had some stale libbabel* stuff in /usr/local/*
Probably that caused it.
I still think the patch would be a good idea to handle such cases, but
it's not needed for the common case.
-Andi