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

[Tim Gardner]

On 08/16/2011 08:49 AM, Stefan Bader wrote:
> On 14.08.2011 18:16, Ben Hutchings wrote:
>> On Tue, 2011-08-02 at 11:38 +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...
>>
>> You *must* set HAVE_CPLUS_DEMANGLE; see Debian bug #606050.
>>
>> Ben.
>>
>>
> Ah ok. Well I saw that setting that option preventing any linkage against
> libbfd. Which was what the proposed patch caused by accidentally breaking all
> the compile time tests.
> What I was not sure of was whether using libiberty only instead of libbfd has
> any functional drawback. But if there are actually license problems involved[1],
> then there does not seem to be a way around only using libiberty.
>
> So the change would be like attached for Oneiric. The milage for other releases
> will vary. The only thing that makes me wonder whether this correct is that ldd
> on the resulting binary shows no reference to libiberty.
>
> -Stefan
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606050
>
>


-- 
Tim Gardner tim.gardner at canonical.com