From: Keith M. <kei...@us...> - 2016-12-03 16:12:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/12/16 00:47, DAVENPORT, MARC wrote: > Thank you for looking into this. The whole problem arises because > cmake incorrectly detects strerror_s in MinGW gcc 5.3.0. No it doesn't, for GCC-5.3.0 does not provide it. However, it may (correctly) detect it in mingwrt-3.22.x. I know users often fail to make that distinction, but it is rather important. > Allegro uses strerror_r and strerror_s when they are available and so > latest Allegro from GIT fails to build because they are not actually > present. strerror_r() isn't, but strerror_s() actually *is*, (provided you are prepared to sacrifice application portability to pre-Vista versions of Windows). > The call to cmake's check_function_exists(strerror_s) incorrectly > reports it's presence. No, it *correctly* reports its *visibility*, just as this autoconf fragment does: $ cat configure.ac AC_INIT AC_PROG_CC AC_CHECK_FUNCS([strerror_s]) $ autoconf $ ./configure --host=mingw32 --build=linux checking for mingw32-gcc... mingw32-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether mingw32-gcc accepts -g... yes checking for mingw32-gcc option to accept ISO C89... none needed checking for strerror_s... yes > This is with latest cmake installed. I plan to report it to cmake > soon. Maybe hold off on that; I don't think cmake is at fault here. See, both cmake and autoconf correctly detect strerror_s() *visibility*; the issue is more that the basic tests performed are insufficient to establish *usability*; this may require a declared prototype in some header, which right now, MinGW lacks. Adding this would not be too difficult, but it needs someone with incentive to make it happen; if you wait for me to get around to it, it may take some time. > If MinGW provided a strerror_r function it would solve this problem > nicely. As, presumably, would adding an appropriate strerror_s() prototype, although that would, of necessity, require a feature test to restrict its use to (user specified) _WIN32_WINNT >= _WIN32_WINNT_VISTA, thus precluding application support for legacy platforms. It is important, to some users, that MinGW.org continues to provide such support, and IMO, addition of strerror_r() would be a better choice for that. > But like you said, it needs to be thread safe. Yes. As I noted, my tentative implementation may already fit the bill, but it would require development of unit tests to confirm it. Unless someone else steps forward, to help out with that, it isn't going to happen any time soon; I simply don't have the time to do it all on my own. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJYQu7WAAoJEMCtNsY0flo/nF0P/2l3HZMMkjXF+LJIH/YlLEWP vdOWgjJMEQdYMqFqjAnZ5FfopWvJspxeEa93JIrEcIzUUS26FBzNL2Geac+h1KOo hxIVYckXALHeI6fPeqNtpKpSPJUvnh9rGBIEgyf4qjISIjnNaQZSdrHS8Ao2WFi/ NUMJmdyjfkj60fRpnt7R3AUUQuehFH5ccno1+U1aHBfqxkMjg3X4fZwRKXd0ZX4l B5HWutZA82HhEszRQPI4eoF8yGHRWrn/RtSl71KiRBw5Rnji3Vui+nkELkYJnUZj a0IPEg33MOjIhGJQfPiHUY1eaqGpzPD4tOX0ALMXLukhSgNYzu8rBf9aO40k28Mx +/Gj4d0mm+2B2ElbA0pbm+75HmjsvTfujA5MnGd+Q7DvaX3ObTdtp3MIQxDze2TE FLtkmnH87HoI/TyXpKzV/6H+pXRfFwi50+WCzI43eEaMbAyOGGnLUFj7Mvd2DtDG DT6+BEQUL6ZNVX6NU9mHc1UTHeHA7GeJRL3PkuwSPR3+csFpYPgfk6wLxvwD2mwN K0kp013F9LGA+xVhPw3MrUh27ZaoIlzAeo93q7yYUegxYx1VJrT3P67CzObo/Z28 eyzgTyY/QIm3ZK+OCQy7DSHurqhBn8fZYpiJy5Ne/cfWVgd0EqUKL+h9oSJRmQis 4cDymvUkI5vxRIRmbNju =9sqY -----END PGP SIGNATURE----- |