Bug#556064: FTBFS with binutils-gold
On Thu, Feb 10, 2011 at 1:41 PM, Julien Cristau <jcristau@debian.org> wrote:
> On Fri, Jan 15, 2010 at 21:55:24 -0500, James Vega wrote:
>
>> reassign 556064 libxft-dev 2.1.12-3
>> retitle 556064 fontconfig incorrectly listed as a private library
>> thanks
>>
>> As shown below, the patch introduced in #389831 incorrectly moved
>> fontconfig to Requires.private. Thus, packages linking against Xft with
>> --no-add-needed (or binutils-gold) FTBFS. This can also be verified by
>> seeing that many of the symbols defined by Xft are simply a #define of
>> XftFoo to FcFoo.
>>
> All those macros are in the XftCompat header though, which seems to
> imply that users should use the fontconfig names instead nowadays, and
> link to fontconfig themselves?
> A similar change is now upstream in libXft 2.2.0 fwiw:
> http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=8751e341bcc29952b4603e18767ab994653c6b01
I don't see any includes for XftCompat, only Xft.h, in the plt-scheme
code (well the wxxt code they were using) that was failing.
Regardless, plt-scheme (now racket) has removed the code that was
using this, so it doesn't affect me anymore.
Hmm, looking into it, Xft.h includes XftCompat.h unless
_XFT_NO_COMPAT_ is defined and portions of their API still directly
ask for (XftTextExtents*) and return (XftFontMatch) fontconfig types.
If the expectation is that Xft users shouldn't be using either the
XftCompat defines or XftFontMatch and as such don't need to link
against fontconfig, I'm fine with that but it should be called out in
the documentation and noted that doing so does require explicit
linking against fontconfig. Instead, they're currently taking the
route of providing API compatibility but dropping the required
information to actually build with that compatibility, as I understand
it.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
Reply to: