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

[Stefan Bader]

On 02.08.2011 16:58, Stefan Bader wrote:
> 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.
> 
> 
Doh! I finally understand what is going on... Basically the change of

-		FLAGS_BFD=$(ALL_CFLAGS) $(ALL_LDFLAGS) $(EXTLIBS) -lbfd
+		LIBBFD := $(shell $(CC) -print-file-name=libbfd.a)
+		FLAGS_BFD=$(ALL_CFLAGS) $(ALL_LDFLAGS) $(EXTLIBS) $(LIBBFD)

completely breaks the compile tests, after. So we start the section without the
define, then fail all the checks for have_bfd, have_... and end up in the "do we
have at least iberty?" which succeeds.
But that is unlikely the thing we want (to use bfd but statically linked). So
sorry for the noise, but the patches submitted are wrong as well.

-Stefan