freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Announcing FreeType 2.10.3


From: Chris Liddell
Subject: Re: Announcing FreeType 2.10.3
Date: Fri, 16 Oct 2020 11:35:21 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 12/10/2020 18:00, Chris Liddell wrote:
> On 12/10/2020 17:47, Alexei Podtelezhnikov wrote:
>>
>>     > So, we've had a report that building Ghostscript against Freetype
>>     > 2.10.3 fails because FT_CALLBACK_DEF() has been moved to internal
>>     > use only.
>>     >
>>     > Ghostcript supplies callbacks for memory management
>>     > (i.e. FT_MemoryRec) and we used FT_CALLBACK_DEF() for those, which
>>     > seemed logical when defining callbacks!
>>
>>     Looks like an oversight to make it internal.  Fact is that this macro
>>     is not publicly documented...
>>
>>
>> The internal description suggests that this is a placeholder for
>> __attribute__((fastcall)) and __atribute__((cdecl)), which we do not use
>> ourselves.
>>
>>     > Is there now an alternative way to do that?  Or should we just
>>     > switch to explicitly declaring them static?
>>
>>
>> Would ghostscript like to use those attributes?
> 
> I don't see any compelling reason for us to do so.
> 
> As I said, I'm quite happy just changing our callbacks to be directly
> declared static functions. I just want to check that's what's intended,
> and that there isn't a replacement for/alternative to FT_CALLBACK_DEF()
> that we should be using.

So, in the absence of any alternative guidance, I'm going with the
change to explicitly define the gs/ft callbacks as static.

Chris




reply via email to

[Prev in Thread] Current Thread [Next in Thread]