[PATCH 1/4] shadowfb calls GetGlyphs() so list libXfont as a dependency

Yaakov (Cygwin/X) yselkowitz at users.sourceforge.net
Mon Jun 25 01:24:02 PDT 2012


On Sun, 2012-06-24 at 09:31 -0700, Alan Coopersmith wrote: 
> I was thinking of making it so that libXfont didn't call those functions
> directly, but required the caller to call a new "init callbacks" API that
> passed in pointers to them, much like the RegisterFPEFunctions functions
> does for each font backend.  Alternatively, we could just drop the weak
> stubs and require all callers to provide all those functions - currently
> I see three remaining users of libXfont - the X server, xfs, & bdftopcf.
> I suspect for bdftopcf the best long term plan is to move it to using
> freetype instead of libXfont, and then we're left with the two servers
> which already implement most of those functions and shouldn't need weak
> versions, but that wouldn't allow "-no-undefined" linking for it, while
> an init callbacks API would.

Right, I suspect the first option would be better.

> But in looking at what it would take to do that I found a much simpler
> solution for this case, since GetGlyphs() is not a weak-linked function,
> and not used by anything but the X server & its modules, and is just a
> simple wrapper around the public API of libXfont, not using any private
> implementation details - just move it to the Xserver.   It's even already
> listed in dixfonts.h as a function the X server exports, so this is just
> simplifying the linker work to make it available to callers.
> 
> So replace the original [PATCH 1/4] with the following which adds
> GetGlyphs() to dixfonts.c, making all platforms export it from the same
> binary, instead of differing based on how libXfont is linked.

Sorry, but that doesn't work either:

/usr/lib/libXfont.a(fontutil.o): In function `GetGlyphs':
libXfont/src/util/fontutil.c:54: multiple definition of `_GetGlyphs'
../../dix/.libs/libdix.a(dixfonts.o):dix/dixfonts.c:123: first defined
here


Yaakov
Cygwin/X




More information about the xorg-devel mailing list