Patchwork [Oneiric] perf: Fix libbfd usage

login
register
mail settings
Submitter Stefan Bader
Date Aug. 17, 2011, 1:24 p.m.
Message ID <1313587473-7699-1-git-send-email-stefan.bader@canonical.com>
Download mbox | patch
Permalink /patch/110317/
State New
Headers show

Comments

Stefan Bader - Aug. 17, 2011, 1:24 p.m.
From the discussion on the mailing list this not only is a matter
of having libbfd not linked dynamically but not at all (the licence
seems incompatible). So we probably should start to remove it for
Oneiric and follow up with older releases...

This changes the used demangling function from the one in libbfd to
the one in libiberty (which is available only as a static library)
but according to Ben, there is no difference. And it seems Redhat
also had to go that way.

-Stefan

From 19c6b33d1b1ff39df7943716d9b8cee30f71adc8 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Tue, 16 Aug 2011 16:14:22 +0200
Subject: [PATCH] UBUNTU: (build) Force perf to use libiberty for demangling

Because libbfd is GPLv3 only and perf is GPLv2 only. Also this avoids
statically linking against libbfd to allow multiple versions of perf
being installed in parallel.

See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606050

BugLink: http://bugs.launchpad.net/bugs/783660

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 debian/rules.d/2-binary-arch.mk |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
Stefan Bader - Aug. 17, 2011, 4:45 p.m.
Ok, so it seems Natty, Maverick and Lucid all have the switch in the makefile.
So the same change (with minor variations) would work on them as well. I have
not really thought about topic branches. Actually not sure the arm side has perf
in use at all. And I think if ec2 has it, it uses the same rules. But I will
cross check when looking at the rebases...

-Stefan
Tim Gardner - Aug. 17, 2011, 4:51 p.m.
On 08/17/2011 10:45 AM, Stefan Bader wrote:
> Ok, so it seems Natty, Maverick and Lucid all have the switch in the makefile.
> So the same change (with minor variations) would work on them as well. I have
> not really thought about topic branches. Actually not sure the arm side has perf
> in use at all. And I think if ec2 has it, it uses the same rules. But I will
> cross check when looking at the rebases...
>
> -Stefan
>

Acked-by: Tim Gardner <tim.gardner@canonical.com>
Andy Whitcroft - Aug. 18, 2011, 9:43 a.m.
On Wed, Aug 17, 2011 at 03:24:33PM +0200, Stefan Bader wrote:
> From the discussion on the mailing list this not only is a matter
> of having libbfd not linked dynamically but not at all (the licence
> seems incompatible). So we probably should start to remove it for
> Oneiric and follow up with older releases...
> 
> This changes the used demangling function from the one in libbfd to
> the one in libiberty (which is available only as a static library)
> but according to Ben, there is no difference. And it seems Redhat
> also had to go that way.

Does this mean we can revert the previous change?

-apw
Stefan Bader - Aug. 18, 2011, 10:36 a.m.
On 18.08.2011 11:43, Andy Whitcroft wrote:
> On Wed, Aug 17, 2011 at 03:24:33PM +0200, Stefan Bader wrote:
>> From the discussion on the mailing list this not only is a matter
>> of having libbfd not linked dynamically but not at all (the licence
>> seems incompatible). So we probably should start to remove it for
>> Oneiric and follow up with older releases...
>>
>> This changes the used demangling function from the one in libbfd to
>> the one in libiberty (which is available only as a static library)
>> but according to Ben, there is no difference. And it seems Redhat
>> also had to go that way.
> 
> Does this mean we can revert the previous change?
> 
> -apw

We could if we did. AFAICS current Oneiric master-next only has one patch about
that issue and that is the one defining HAVE_CPLUS_DEMANGLE. Sorry, there might
have been confusion because I reposted the patch as it seemed to be lost in the
lengthy discussion.

-Stefan
Andy Whitcroft - Aug. 18, 2011, 11:30 a.m.
On Thu, Aug 18, 2011 at 12:36:06PM +0200, Stefan Bader wrote:
> On 18.08.2011 11:43, Andy Whitcroft wrote:
> > On Wed, Aug 17, 2011 at 03:24:33PM +0200, Stefan Bader wrote:
> >> From the discussion on the mailing list this not only is a matter
> >> of having libbfd not linked dynamically but not at all (the licence
> >> seems incompatible). So we probably should start to remove it for
> >> Oneiric and follow up with older releases...
> >>
> >> This changes the used demangling function from the one in libbfd to
> >> the one in libiberty (which is available only as a static library)
> >> but according to Ben, there is no difference. And it seems Redhat
> >> also had to go that way.
> > 
> > Does this mean we can revert the previous change?
> > 
> > -apw
> 
> We could if we did. AFAICS current Oneiric master-next only has one patch about
> that issue and that is the one defining HAVE_CPLUS_DEMANGLE. Sorry, there might
> have been confusion because I reposted the patch as it seemed to be lost in the
> lengthy discussion.

Ahh.  In that case it looks sane and simple:

Acked-by: Andy Whitcroft <apw@canonical.com>

-apw

Patch

diff --git a/debian/rules.d/2-binary-arch.mk b/debian/rules.d/2-binary-arch.mk
index 29788fc..466c8a4 100644
--- a/debian/rules.d/2-binary-arch.mk
+++ b/debian/rules.d/2-binary-arch.mk
@@ -365,7 +365,8 @@  endif
 
 $(stampdir)/stamp-build-perarch: prepare-perarch
 ifeq ($(do_tools),true)
-	cd $(builddir)/tools/tools/perf && make $(CROSS_COMPILE)
+	cd $(builddir)/tools/tools/perf && \
+		make HAVE_CPLUS_DEMANGLE=1 $(CROSS_COMPILE)
 	if [ "$(arch)" = "amd64" ] || [ "$(arch)" = "i386" ]; then \
 		cd $(builddir)/tools/tools/power/x86/x86_energy_perf_policy && make $(CROSS_COMPILE); \
 		cd $(builddir)/tools/tools/power/x86/turbostat && make $(CROSS_COMPILE); \