On Wed, Jun 01, 2016 at 09:47:50AM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Jun 01, 2016 at 10:40:15AM +0200, Jiri Olsa escreveu: > > On Tue, May 31, 2016 at 11:19:11AM +0000, He Kuang wrote: > > > SNIP > > > + ifeq ($(feature-libunwind-x86), 1) > > > + $(call detected,CONFIG_LIBUNWIND_X86) > > > + CFLAGS += -DHAVE_LIBUNWIND_X86_SUPPORT > > > + LDFLAGS += -lunwind-x86 > > > + have_libunwind = 1 > > > + endif > > > > ifneq ($(feature-libunwind), 1) > > > msg := $(warning No libunwind found. Please install > > > libunwind-dev[el] >= 1.1 and/or set LIBUNWIND_DIR); > > > NO_LOCAL_LIBUNWIND := 1 > > > +++ b/tools/perf/util/Build > > > @@ -101,6 +101,7 @@ libperf-$(CONFIG_DWARF) += dwarf-aux.o > > > libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o > > > libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind-local.o > > > libperf-$(CONFIG_LIBUNWIND) += unwind-libunwind.o > > > +libperf-$(CONFIG_LIBUNWIND_X86) += libunwind/x86_32.o > > > > seems odd but I dont have any better idea.. let's see what > > others have to say ;-) > > There was a lot of discussion in this patchkit, so I lost track of why I > should consider the above odd :-) > > I.e. I take the above as: if x86 libunwind was detected or explicitely > selected, link support for it when generating the perf tool in any > architecture, which seems sensible, no?
yep.. the x86_32 name under generic dir is what seems odd to me, but it's like you said.. anyway we can always change if we find some better solution ;-) jirka
