APPLIED: [Oneiric, Natty, Maverick, Lucid SRU] Link libbfd statically
tim.gardner at canonical.com
Wed Aug 17 13:31:12 UTC 2011
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.
> 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,
> 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.
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606050
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team