|
From: Keith M. <kei...@us...> - 2015-03-10 04:35:45
|
Hi David, On 05/03/15 21:42, David Gressett wrote: > The offending line of code is protected inside an #ifdef HAVE_UMASK. I suspect that this may be a red herring. Searching the config.log files, throughout my cross-native build tree for mingw32-gcc-4.8.2, (built against previous mingwrt-3.20), yields references only when building libgfortran; these show: checking for umask result: yes . . #define HAVE_UMASK 1 so it would appear that HAVE_UMASK would have been defined for the earlier case anyway. > This leads me to believe that something in mingwrt 3.21 is causing the > gcc 4.9.2 build to be misconfigured and it is causing HAVE_UMASK to > be defined when it should not be, ... I'm not convinced; see above. > ... so that the build is compiling code that should not be compiled > for Windows. I should file a ticket for this, but I would like to be > able to propose a patch when I do that. > > Does anybody have any idea what could be causing this? The next > step is to compare the present and previous versions of mingwrt, > but I don't want to waste time reinventing wheels that someone else > already knows about. The only change that I can think of, which might have a bearing, is that _mingw.h now defines _POSIX_C_SOURCE as 200809L, unless you use an option which implicitly sets __STRICT_ANSI__, or explicitly set a lower standard of POSIX.1 compliance. However, if that is the case, it would tend to indicate that GCC is not testing features appropriately, for as I read the POSIX.1 standards, _POSIX_C_SOURCE is not a promise that any specific feature will be available, but rather a request to expose all features for a specific POSIX.1 version which a particular implementation is able to support. Beyond this, I have no suggestions to offer; you'll need to investigate the issue for yourself, as I simply don't have time to look into it ATM. -- Regards, Keith. |