Re: [Mingw-users] S_IRWXG, S_IRWXO undefined when building gcc 4.9.2 with mingwrt 3.20

[Keith M. <kei...@us...>]

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.