autoconf
[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: Keith Marshall
Subject: Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers
Date: Sat, 31 Mar 2007 00:04:53 +0100
User-agent: KMail/1.8.2

On Friday 30 March 2007 00:38, Ralf Wildenhues wrote:
> > I'm curious as to the rationale behind this decision to insist of
> > linker output files to pass `test -x';

Reading this again, I'm appalled by my sloppy English; of course I meant 
to write `...insist on linker output files passing...'.  Sorry.

> I don't think there exists any "insistence" except for having omitted
> considering the case of a MinGW/MSYS -> $other cross build, when this
> change was done.
>
> > it must surely break cross-compilation
> > on any $build platform which doesn't conform to the Unix notion of
> > what designates a file as executable.  Can you point me to some
> > documentation which explains why it is necessary?
>
> No.  But many platforms are pretty unixy in this respect.

Granted, but striving for portability, autoconf can't *ever* rely on 
this; many != every, which AIUI is autoconf's goal, subject only to the 
availability of a Unixy shell.  While MSYS strives to provide a Unixy 
shell, it has to work within the limitations of the underlying Win32 
OS, and that means the ability to identify a file as executable must 
rely on the file name extension, with the one exception of shebanged 
script files.
 
> And broken compilers or broken setups sometimes leave output files
> which aren't executable, so testing that bit would have helped for
> them IIRC.

Ok. I understand why that might be a problem.  The reverse of that coin 
is that cross compilers leave output files which are executable on the 
$host platform, but not on $build, and `test -x' on $build may fail for 
those; in accommodating the broken behaviour, you break the legitimate.

> The fix should add a comment about this setup, so we don't forget
> again why we cannot use -x.

Just some food for thought: eyeballing a simple configure script, 
generated by autoconf-2.61, in the region which I believe originates in 
AC_INIT, I see:

  if test -x / >/dev/null 2>&1; then
    as_test_x='test -x'
  else
    # do something frighteningly complicated and barely comprehensible
    # (my comment, not in actual code)...

which:--

1) Tests for accessibility to search within the root directory, and has 
nothing to do with executability of files; MSYS will pass this test, so 
$as_test_x will be assigned as `test -x', even though this will then 
fail, when testing for an executable conftest$ac_exeext, created by a 
cross compiler, for which $ac_exeext is empty.

2) Seems to me to be misplaced; would the initialisation of as_test_x 
not be better deferred, to within the actual code invoked by AC_PROG_CC 
and friends, which initialises ac_exeext itself?  Doing it that way, 
you would then have an actual file, expected to be executable, to which 
you could apply the `test -x', setting as_test_x to a no-op if it fails 
there, when in cross compiling mode.

Regards,
Keith.




reply via email to

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