Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers

[Keith MARSHALL]

>> As I read the background discussion, leading to introduction of this
>> extended test, it appears that it was introduced to appease one broken
>> compiler suite,
> Wrong. 
> 
> It was triggered by running standard autoconf-2.61 configure scripts on
> MinGW and Cygwin.

I beg to differ.  The extended test was introduced to appease a (broken)
compiler suite, running on Tru64.  That extended test subsequently exposed
a limitation on Win32--not inherently a MinGW/Cygwin limitation, but of
the base Win32 OS itself.

>>  running on an elderly minority platform. 
> ... if you want to label MinGW with this attribute, I agree.

I don't.  I was referring to the outdated version of Tru64, to which the
original bug report referred.

>> it has broken a feature of autoconf itself, on a current and widely
>> deployed platform, namely Microsoft Windows.
> Wrong again.
>
> It is triggered by MinGW/Cygwin's "test -x" behavior diverging from
> POSIX:

So what?  Win32 is not, and does not claim to be POSIX.  MinGW and Cygwin
do the best they can, to emulate POSIX features on this non-POSIX system;
(Cygwin does so more comprehensively; MinGW deliberately adopts a more
minimalist approach).  If autoconf aims to support users on this platform,
(which it generally achieves quite well), then it needs to accommodate the
non-POSIXness of the system.

> NOTE: [The] definition is completely independent from a file being a
> executable natively on a platform.

It is, but there is a non-stated implicit requirement that the host
file system provides a mechanism for identifying a file as having
`executable permission', on at least some host...

> To me this reads as: MinGW and Cygwin's "test -x" are broken.

...yes, in the POSIX sense, they are.  They do the best they can, given
the limitations of the underlying OS and file systems.

> Wrt. autoconf this would mean: "test -x" is non-portable...

That's absolutely correct...

> autoconf must not use it anywhere.

...but it need not be so draconian; it can perform some up-front testing,
to identify where it may not be safe to use it.

> The way easier approach however would be MinGW and Cygwin to be fixed.

Not so.  That would require making Win32 POSIX compliant, which in turn
would require the co-operation of Microsoft.  I don't think that's likely
to happen, any time soon.

Regards,
Keith.