autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ralf Corsepius
Subject: Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers
Date: Thu, 12 Apr 2007 19:17:03 +0200

On Thu, 2007-04-12 at 11:04 -0600, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Ralf Corsepius on 4/12/2007 10:43 AM:
> > On Thu, 2007-04-12 at 05:12 -0600, Eric Blake wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> According to Ralf Corsepius on 4/12/2007 4:46 AM:
> >>> To me this reads as: MinGW and Cygwin's "test -x" are broken.
> >> Give an example where cygwin's "test -x" is broken.
> > RTEMS users have reported it for both MinGW and for Cygwin.
> > 
> > Cf. these are the Cygwin variant:
> > http://rtems.rtems.org/pipermail/rtems-users/2007-March/017888.html
> 
> OK, thanks for the pointer - that mail is an example of a cross compiler,
> run on cygwin, but generating non-cygwin files and on a file system that
> lacks executable permission bits.
Why should permission bits matter?

What matters is the executable bit. AFAICT, even old FAT had them.

>   It provides more proof that
> cross-compilers need not do the -x check,
Could you please elaborate why autoconf would a need any -x check at
all?

>  so the recent checkin that only
> turns off -x checking for cross-compilers was correct.
IMO, it is playing with symptoms. Either this -x is always relevant or
it is never relevant.

>   I was more worried
> that you might have come up with an instance where a cygwin native
> executable test was failing.
IMO, the reports proves Cygwin's and MinGW's "test -x" to be defective.

As a consequence of this, this render using "test -x" on both Cygwin and
MinGW a random accident and (in our case) qualify Cygwin and MinGW as
non-suitable hosts for cross-compilation.

Ralf







reply via email to

[Prev in Thread] Current Thread [Next in Thread]