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

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?

> 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.

> However, there are now other issues which prevent glib2 from building > successfully (libgsf and libsoup built just fine). > > For glib2: > ../../gio/gsocket.c:1934:1: error: conflicting types for > 'if_nametoindex' > if_nametoindex (const gchar *iface) > ^ > In file included > from /usr/i686-w64-mingw32/sys-root/mingw/include/iphlpapi.h:16:0, > from ./gnetworking.h:35, > from ../../gio/gnetworkingprivate.h:22, > from ../../gio/gsocket.c:60: > /usr/i686-w64-mingw32/sys-root/mingw/include/netioapi.h:321:20: note: > previous declaration of 'if_nametoindex' was here > NET_IFINDEX WINAPI if_nametoindex( > ^ > > My first guess is that this needs to be fixed in glib2 itself and that > it is unrelated to your patch Yeah, that would be my guess too.