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

[Stefan Bader]

On 02.08.2011 16:29, Tim Gardner wrote:
> 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
> 
So if that is the case, why does compiling on the builders result in a different
outcome compared to chroot compile (both have the dependencies)
Also changing the Makefile to set HAVE_CPLUS_DEMANGLE again is a change to the
Makefile.
I would like to understand why and if it is possible to avoid that modification
to generic code, I think that is better to maintain. Ok, you probably can set it
in the call in rules.d...

> Why are you not Cc'ing kernel-team at lists.ubuntu.com on your responses ?
> 
Because you did not Cc it in your mail which I was answering... :) Ok, I could
have added the cc again. But was not sure whether you intentionally wrote only
directly.