[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