[Mingw-w64-public] Mass rebuild report for January 03 2015

Kai Tietz ktietz70 at googlemail.com
Tue Jan 6 12:54:26 UTC 2015


2015-01-06 13:26 GMT+01:00 Jacek Caban <jacek at codeweavers.com>:
> On 01/06/15 12:49, Kai Tietz wrote:
>> 2015-01-06 12:22 GMT+01:00 Jacek Caban <jacek at codeweavers.com>:
>>> On 01/05/15 21:58, Erik van Pienbroek wrote:
>>>> Jacek Caban schreef op ma 05-01-2015 om 14:05 [+0100]:
>>>>> On 01/04/15 12:49, Jacek Caban wrote:
>>>>>> Maybe I missed some better options for us. None of above is perfect and
>>>>>> I'm not sure what we should do about it. Solution 2. seems the least
>>>>>> problematic.
>>>>> Looking deeper at this, current implementation has one more problem. We
>>>>> can't really have localtime_r, because it needs to depend on
>>>>> _USE_32BIT_TIME_T macro. So if we really wanted to have a real function
>>>>> in mingwex, we'd need it as localtime32_r and localtime64_r and an
>>>>> inline wrapper. Given that, I think we should live with inline
>>>>> implementation. Esp. since we may use localtime_s (which already has
>>>>> wrapper inline as well as compatibility stub in libmsvcrt.a), which
>>>>> makes the implementation trivial. Please review the attached patch. I
>>>>> believe we should do the same for ctime_r and asctime_r.
>>>> Hi Jacek,
>>>>
>>>> Thanks for the patch. I just tested it and I can confirm that it solves
>>>> the localtime_r issue in glib2 and the gmtime_r issues in libgsf and
>>>> libsoup.
>>> Thanks for testing. Kai, what do you think, should I commit the patch?
>> Sure.  Patch is ok.
>
> OK, committed.
>
>>>>  The cmtime_r issue in cairo is not resolved yet with this
>>>> patch, but I guess this is expected for now.
>>> Yeah, I may prepare a patch for that as well if we decided to go this way.
>> This route makes sense IMO.  So what are others thinking about it?
>
> The attached patch implements that. Please review.
>
> Thanks,
> Jacek

Patch is ok.  (To be consistent here).

Only thing I am concerned is that those functions don't have anymore a
unique function-pointer over complete TU anymore.  But this should be
no big issue, beside maybe for C++ ...

Kai


More information about the mingw mailing list