Hi Erik, On 03/01/15 23:24, Erik van Pienbroek wrote: > Sandro Mani schreef op za 03-01-2015 om 22:24 [+0100]: >>>> mingw-poppler-0.28.1-1 >>>> ** Package failed to build while it succeeded during the previous mass >>>> rebuild ** >>>> Package owner: smani >>>> Time to build: 2 minutes, 25 seconds >>>> Build logs: >>>> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-poppler-0.28.1-1 >>> Failed with: error: 'gmtime_r' was not declared in this scope >>> >> gmtime_r in time.h is declared inside a >> >> #if defined(_POSIX) || defined(_POSIX_THREAD_SAFE_FUNCTIONS) >> >> block. Apparently, neither are defined when compiling with mingw. >> >> time.h has changed significantly (also with regard to gmtime_r) after >> mingw-poppler was last built (using >> mingw-headers-3.9.999-0.1.trunk.git.b08afb.20140912.fc22). I'm not sure >> whether this is a mingw-headers bug or something else? > These issues with gmtime_r and localtime_r are most likely issues in the > mingw-w64 headers as multiple packages are affected by it. > Please keep the CC intact as this report was sent to both the Fedora > MinGW mailing list and the upstream mingw-w64 mailing list so we can > help each other in resolving these issues.
I've hit the problem in Mozilla builds as well. This is a problem since those functions were added to mingwex. This caused autoconf scripts to find those functions (because they can be found in link time). However, their declarations are guarded in headers, which is not expected by code that uses them. I fixed the problem in Mozilla sources, but we should discuss what to do on mingw-w64 side so that other projects don't have the problem or at least have a clear signal how to fix it. 1. We could remove those guards. This will cause problems with existing code. I've seen cases, where those functions were not expected to be present in Windows builds and project adds its own implementation of them. This causes conflict with mingw-w64 declaration. 2. We could keep guards and hide implementations in mingwex. Hiding it is easy. We could for example prefix names with __mingw_* and have forwarding inlines in headers. Other option would be to go back to have them implemented as pure inlines. This will protect existing code from regressions, because autoconf scripts won't find those functions, but it may be considered as a bad thing. 3. We could both remove guards and hide implementations in mingwex. Well, this would have both problems of 1. and 2. 4. Keep things the way they are and expect affected code to fix it. The problem about this is obvious. 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. To give a real world examples of the problem (Mozilla sources), here is a fix to make the implementation independent of localtime_r and use localtime_s explicitly in case of Windows builds [1] to avoid problems that only solution 2. would fix on mingw-w64 side. If we go with a fix like 1., there will be one more place I will have to fix [2] (static vs non-static declaration conflict). Jacek [1] http://hg.mozilla.org/mozilla-central/rev/5dba1e33ab69 [2] http://hg.mozilla.org/mozilla-central/file/55f3224d7513/security/pkix/test/lib/pkixtestutil.cpp#l226 ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
