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

Tim Gardner tim.gardner at canonical.com
Tue Aug 2 13:15:03 UTC 2011


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?

-- 
Tim Gardner tim.gardner at canonical.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20110802/10c4dd21/attachment.txt>


More information about the kernel-team mailing list