[HarfBuzz] compilation error of 0.9.26 with MinGW

[Behdad Esfahbod]

Thanks.  I pushed a similar change out that should fix.  Please test.

On 14-02-05 02:33 AM, Werner LEMBERG wrote:
> 
>>> hb-common.cc: In function 'hb_language_item_t* lang_find_or_insert(const char*)':
>>> hb-atomic-private.hh:61:47: error: expected primary-expression before ')' token
>>>  #define hb_atomic_ptr_get(P)  (MemoryBarrier (), (void *) *(P))
>>
>> Interesting.  Can you try the attached patch?  Looks like a MinGW
>> bug to me.
> 
> It seems to be a bug in MinGW, see
> 
>   https://sourceforge.net/p/mingw/bugs/2131/
>   https://sourceforge.net/p/mingw/bugs/2181/
> 
> Maybe you can add comments there, if necessary.
> 
> Applying the recommended fix from those two bug reports, however,
> fails for me; macro expansion then reduces
> 
>   hb_language_item_t *first_lang =
>     (hb_language_item_t *) hb_atomic_ptr_get (&langs);
> 
> to
> 
>   hb_language_item_t *first_lang =
>     (hb_language_item_t *) (, (void *)&langs)
> 
> which the compiler still doesn't like.
> 
> Running MinGW natively on a Win7 box, I admit that I have no idea why
> MinGW expands to the fallback macro, which is empty – maybe you have
> to explicitly define the Windows version (via the _WIN32_WINNT macro)
> to be something equal to or newer than Vista?  On the other hand, I
> think that the original HarfBuzz code isn't correct either, since it
> relies on the fact that `MemoryBarrier' always expands to a function
> call, which is obviously not true.
> 
> The good news: Your patch works :-)  To avoid warnings, you should
> insert
> 
>   # undef MemoryBarrier
> 
> before (re)defining `MemoryBarrier'.
> 
> 
>     Werner
> 

-- 
behdad
http://behdad.org/