Orphaning libunwind

[Jiri Olsa]

On Mon, Nov 26, 2012 at 10:00:52AM -0500, Josh Boyer wrote:
> On Mon, Nov 26, 2012 at 9:41 AM, Jiri Olsa <jolsa at redhat.com> wrote:
> > On Mon, Nov 26, 2012 at 09:34:35AM -0500, Josh Boyer wrote:
> >> On Mon, Nov 26, 2012 at 9:29 AM, Jiri Olsa <jolsa at redhat.com> wrote:
> >> >> > If perf winds up getting stuck relying on an orphaned library for some
> >> >> > non-trivial amount of time,
> >> >>
> >> >> AFAIK that is common in Fedora there are orphaned libraries in use for
> >> >> a release or two.
> >> >>
> >> >>
> >> >> > I'd rather just turn off libunwind support in perf now.  It's only enabled
> >> >> > in rawhide at the moment because it is a 3.7 feature.  Before we bring 3.7
> >> >> > back to f17-f18, we should probably decide.
> >> >>
> >> >> That is more a question to Jiri Olsa, the author of perf libunwind client.
> >> >
> >> > it will be configurable for both libunwind and elfutils unwinders,
> >> > and making default the one with better results or available
> >> >
> >> > I should send upstream perf changes within this week
> >>
> >> Those won't make it into the kernel until 3.8 though.  So for 3.7, I'm
> >> thinking we should just disable perf libunwind support entirely.  Once
> >> elf-utils gets its unwinder and the patches for perf hit rawhide we can
> >> turn it back on.
> >
> > currently if the libunwind is not found during build time, it's not compiled in
> 
> Yes, I'm aware of that.  At the moment, it is found because the library
> is in Fedora.  However, I don't want to build 3.7 perf against a library
> that is orphaned and clearly not really supported.  So I'm going to
> disable it with NO_LIBUNWIND=1 and we can revisit perf with unwind
> support for the 3.8 kernel when elf-utils is ready.
> 
> Basically, if something better is going to come along the next version
> then I really don't see a reason to ship the already obsolete and
> orphaned support today.

ok, no problem with that..

jirka