GNOME Bugzilla – Bug 754431
Fix build of glib/gstrfuncs.c on Windows
Last modified: 2017-08-05 23:53:54 UTC
Hi, Commit 36fac0849 introduced the use of strerror_r() which is actually not available on Windows, which will then cause the build on Windows to break. We can just use strerror_s(), which does more or less the same thing and should be thread-safe.
Created attachment 310461 [details] [review] glib/gstrfuncs.c: Fix Build on Windows Hi, Please see the patch. With blessigs, thank you!
Created attachment 310467 [details] [review] glib/gstrfuncs.c: Fix Build on Windows Hi, I was testing the patch against the old DLL, and the previous patch tried to use uninitialized memory, bad :| This is the correct patch. With blessings, thank you!
Review of attachment 310467 [details] [review]: Looks good to me.
Hi Nacho, Thanks for the very quick reviews :)! The patch was pushed as 4cad3f5. With blessings, thank you!
strerror_s only exists in msvcrt.dll since Windows Server 2003 it seems, Windows XP does not have it.
And in mingw only if you #define MINGW_HAS_SECURE_API? That seems weird.
And if we wanted to compile for newer Windows, we run into bug #756868
Created attachment 314258 [details] [review] strerror_s only with _MSC_VER I need this patch to compile with mingw which doesn't have strerror_s.
mingw has it, but only if you #define MINGW_HAS_SECURE_API. See above :) In any case, something definitely needs some changes here
But it is not defined after "./configure"
Yes, someone will have to investigate what this MINGW_HAS_SECURE_API is about in mingw.
mingw-w64-headers defines MINGW_HAS_SECURE_API (in _mingw.h) only if configured with --enable-secure-api, which is not the default. Debian and Fedora build MinGW-w64 with --enable-secure-api for both i686 and x86_64 targets, but Cygwin enables it only for the x86_64 target.
I haven't found any documentation for MINGW_HAS_SECURE_API, so I had a look through the mingw-w64 repo. --enable-secure-api and MINGW_HAS_SECURE_API only affect whether the prototypes for the "security-enhanced" (_s) functions are exposed by the headers. AFAICT the macro is intended to be #defined by application code that is willing to require a newer msvcrt that includes those functions. --enable-secure-api was added later; the commit message doesn't say why, but I suspect it's to prevent newer applications (which may assume the secure functions are available) from having to individually add the #define. If it's okay for glib to depend on a post-XP msvcrt, I think the right fix is to #define MINGW_HAS_SECURE_API 1 before including system headers. If not, strerror_s can't be used.
If I'm not mistaken, mingw will ship it's own implementation of those functions if they are not available in the target msvcrt.
Yes, it seems you're right. The secapi polyfills were added to mingw-w64 starting in August 2012; strerror_s was added in March 2014. Do we care about supporting Windows XP via MSVC builds (or builds with older mingw, I guess)? Bug 736458 (missing rand_s) was fixed by dropping the rand_s call from glib, even though mingw-w64 added a rand_s implementation in June 2013. MINGW_HAS_SECURE_API dates from October 2007, so I guess that macro is a historical artifact now.
Hi Benjamin, (In reply to Benjamin Gilbert from comment #15) > Do we care about supporting Windows XP via MSVC builds (or builds with older mingw, I guess)? It is true that the general consensus from the maintainers' point of view would be to stop supporting Windows XP, as it reached end-of-life quite some time ago. For this bug specifically, on the MSVC side, is that the _s variants should be still supported on XP, as: -The MSVC builds supported are for MSVC 2008 and later, and it is known that at a recent stage there are people that were able to build GLib successfully on MSVC 2005. -The _s variants are supported since MSVC 2005, and they are supported in the CRT DLL that are shipped with the compilers, i.e. msvcrX0.dll, which should run on XP until MSVC 2012 (given that the XP support mode in MSVC 2012+ builds are not enabled). -We don't support at this time building against the Windows DDK officially, which would then link to msvcrt.dll. I can't say very much about the situation on MinGW or mingw-w64, sorry. With blessings.
So it sounds as though we're okay on the MSVC side. Cygwin is now building both MinGW-w64 targets with --enable-secure-api (see comment #12), so unless there's a major distro that still isn't doing that, I think this can be closed?
Let's assume so! If anyone hits this again, please do reopen with the info.