[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.
Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers, Paul Eggert, 2007/03/29