[PATCH] XWin: Fix for static libXfont use

[Jon TURNEY]

On 28/06/2010 13:24, Vignatti Tiago (Nokia-D/Helsinki) wrote:
> On Mon, Jun 28, 2010 at 01:36:31PM +0200, ext Julien Cristau wrote:
>> On Mon, Jun 28, 2010 at 14:20:51 +0300, Tiago Vignatti wrote:
>>
>>> On Mon, Jun 28, 2010 at 12:48:53PM +0200, ext Colin Harrison wrote:
>>>> Hi,
>>>>
>>>> All XWin DDX builds use libXfont built static.
>>>> The following libXfont patch is needed following recent master git changes
>>>> (use of register_fpe_functions from libXfont in the server)...
>>>>
>>>> --- ./src/util/save_miscutil.c  2010-06-21 16:47:00.000000000 +0100
>>>> +++ ./src/util/miscutil.c       2010-06-28 11:25:19.000000000 +0100
>>>> @@ -48,8 +48,10 @@
>>>>
>>>>   extern void BuiltinRegisterFpeFunctions(void);
>>>>
>>>> +#ifndef WIN32
>>>>   /* make sure everything initializes themselves at least once */
>>>>   weak long serverGeneration = 1;
>>>> +#endif
>>>>
>>>
>>> can't we just live without serverGeneration then? My quickly compile&  test
>>> approach here worked well when doing it.
>>>
>> What did you test exactly?  The X server has a non-weak serverGeneration
>> so removing the weak one from libXfont doesn't make a difference there,
>> but it might for other libXfont users.
>
> oh, that's true. I forgot that the server and libXfont is not 1:1 mapping.

What do people think about the attached (untested) patch as an approach?

Since register_fpe_functions() is now called by the server for every 
generation, we can arrange for that to do the needed re-initialization for a 
new server generation, and avoid libXfont needing to track server generations 
itself.

This removes serverGeneration from libXfont, so any client which depends on 
the existence of that weak definition won't build any more, but that seems to 
me to be a strange thing to do...

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-Remove-the-weakly-defined-serverGeneration-variable.patch
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100628/211b4aa1/attachment.ksh>