Using chmod fails under MinGW

[Steve Kargl]

On Fri, Oct 03, 2008 at 06:26:41AM +0200, Arjen Markus wrote:
> > Arjen Markus wrote:
> >
> >> Apparently the chmod subroutine is recognised as an intrinsic,
> >> but there is no suitable implementation.
> >
> > The libgfortran implementation just runs an external chmod binary, but
> > there is no chmod command on native Windows so this would be pointless
> > as it would fail.  Some users might have MSYS or Cygwin installed and
> > thus have an available chmod binary, but users who expect to use just
> > plain MinGW would not.
> >
> > In other words, the semantics of implementing chmod on Windows require
> > some kind of POSIX translation layer, which is not what MinGW is about.
> >
> 
> I can understand that - in fact, a lot of other POSIX routines are
> simply not available, like getuid(). But in these cases the linker
> complains about _getuid being an unresolved external.
> 
> In the case of chmod(), the compiler seems to recognise it as an
> _intrinsic_, given that the symbol the linker is complaining about
> is not called _chmod but __gfortran_chmod_func and the like.
> 
> So, I do think this is a small glitch in the compiler. I just
> confirmd this:
> 

It is not a glitch in the compiler.  You can infer this
by looking at the source.

With _getuid(), gfortran is literally trying to link in a
function named _getuid().

With __gfortran_chmod_func(), gfortran has essentially implemented
the function as (in a psuedo-code)

  function chmod(yada)
  call system("chmod yada", status=chmod)
  return status

That is, gfortran assumes you have a standalone program named chmod,
and it uses a system() call to execute it.  I don't remember if 
libgfortran's configure has the smarts to disable building chmod().
  
The real solution is to dump Windows and MingW if you want to use
all of the nonstandard intrinsic procedures.

-- 
Steve