[Oneiric, Natty, Maverick, Lucid SRU] Link libbfd statically

[Tim Gardner]

On 08/02/2011 07:53 AM, Stefan Bader wrote:
> On 02.08.2011 15:31, Tim Gardner wrote:
>> On 08/02/2011 07:21 AM, Stefan Bader wrote:
>>> On 02.08.2011 15:15, Tim Gardner wrote:
>>>> On 08/02/2011 04:03 AM, Stefan Bader wrote:
>>>>> On 02.08.2011 12:00, Andy Whitcroft wrote:
>>>>>> On Tue, Aug 02, 2011 at 11:38:09AM +0200, Stefan Bader wrote:
>>>>>>> SRU Justification:
>>>>>>>
>>>>>>> Impact: By dynamically linking libbfd, it is not possible to have
>>>>>>> older versions of the perf tool installed (as there can only be one
>>>>>>> version of this lib). Also, Debian policy actually forbids depending
>>>>>>> on a certain version of the library).
>>>>>>>
>>>>>>> Fix: Change the makefile to statically link libbfd. This is a Ubuntu
>>>>>>> specific change, though. Which unlikely will make it upstream.
>>>>>>>
>>>>>>> Testcase: Check the perf version provided though the builders (it
>>>>>>> seems that building in chroots can cause builds not linking against
>>>>>>> libbfd at all as HAVE_CPLUS_DEMANGLE gets set). The ouput of ldd
>>>>>>> should not show libbfd.
>>>>>>>
>>>>>>> Actually, having said this, maybe the better solution is to modify
>>>>>>> the build dependencies to cause the compile to have
>>>>>>> HAVE_CPLUS_DEMANGLE set. That way we do not need to carry a
>>>>>>> modification to the makefile which likely breaks...
>>>>>>
>>>>>> I like the sound of this latter, I think you said we could achieve this
>>>>>> by build-depending oni libiberty instead?  Is that correct?
>>>>>>
>>>>>> -apw
>>>>>
>>>>> No, the main difference seems to be whether HAVE_CPLUS_DEMANGLE is set when
>>>>> doing the compile or not. If it is set, then perf is only linked against
>>>>> -liberty. If not, it can be a combination of -libbfd, -liberty and -lz.
>>>>> I just have not yet found out what actually causes HAVE_CPLUS_DEMANGLE to be
>>>>> set. Its happening in my chroots, but apparently not when building on buildds.
>>>>>
>>>>> -Stefan
>>>>>
>>>>
>>>> Why can't we simply force it to be set in the Debian makefile?
>>>>
>>>
>>> I would suspect that it gets set if something is installed (and somthing which
>>> is not part of the build deps for the kernel). I'd rather get the setup right
>>> that to define something that (likely) is not true...
>>>
>>
>> I guess I don't see what the issue is. The linux package already build-depends
>> on binutils-dev which is the provider of libiberty.a. Why _doesn't_ setting
>> HAVE_CPLUS_DEMANGLE fix the problem ?
>>
>> rtg
>
> It being set in my chroot and not on the builders (and it does not seem to get
> by something in the kernel build before testing it. So it looks to me like "if
> something globally defines it, I can use liberty alone" otherwise the makefile
> goes into various tests to use libbfd, libbfd+liberrty or libbfd+liberty+libz.
> And I am not feeling to well by setting an env variable without really
> understanding what that actually means.
>

It seems pretty clear to me by looking at tools/perf/util/symbol.h that 
if you define HAVE_CPLUS_DEMANGLE, then the ultimate call to demangle a 
symbol is cplus_demangle which is clearly provided by libiberty.a:

nm /usr/lib/libiberty.a | grep cplus_demangle

Why are you not Cc'ing kernel-team at lists.ubuntu.com on your responses ?

-- 
Tim Gardner tim.gardner at canonical.com