AC_NO_EXECUTABLES is useless for GCC

[Alexandre Oliva <aoliva@redhat.com>]

On Dec 10, 2002, Geoff Keating <geoffk@geoffk.org> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> I don't get it.  Why does being able to link have anything to do with
>> being native?  Being able to *run* tests has to do with being native,
>> but that's not the point, and autoconf already avoids running tests
>> when cross-building.  But being able to link has to do with whether
>> the libraries that the compiler links in by default are present or
>> not.  That's the purpose of AC_NO_EXECUTABLES: to disable link tests
>> while building a library that the compiler driver would attempt to link
>> in by default, such as newlib, libstdc++ or libgcj.

> Aah, I see.  No, that's not the purpose of AC_NO_EXECUTABLES, or at
> least it's not what GCC wants out of it.  Some platforms can't link
> anything at all without special care.  For instance, you might need to
> know what board you plan to run the executable on and pass an
> appropriate flag (or supply an appropriate crt0 by hand).  For another
> example, vxworks can't and doesn't link anything, the final link takes
> place at runtime on the board, "executables" are created using 'ld
> -r', and you can refer to any symbols you like in the hope that
> they'll be available later.

I see.  Oh, well...  I was missing this bit of info when I designed
AC_NO_EXECUTABLES :-(  My apologies...

> It's assumed that in a native case, this sort of thing won't happen,
> thus the existing behaviour.  Maybe instead you could perform a
> configure-time test to see if the platform can link anything at all
> (and will fail to link with an obviously bogus symbol), and then base
> the decision of whether to run link tests on that, instead of the
> current approximation, but there'll still be some cases when linking
> is not possible, and other cases (the majority) in which link tests
> are possible and desirable.

I think we'll be better served by declarative macros such as
AC_{CC,CXX,...}_LINK_MAY_FAIL, that modify the autoconf-generated
sanity link test for AC_PROG_{CC,CXX,...} such that it does not bail
out if it fails, but rather it sets a variable indicating the result
of the test, such that we could base our decision on whether to
perform additional link tests on this variable.  Does it sound like
this would work?

Do we actually need AC_*_LINK_MAY_FAIL, or would a single
AC_LINK_MAY_FAIL macro be sufficient for libstdc++ and libgcj's needs?


Or perhaps we could make do with a configure argument that would tell
autoconf it's ok if the initial link test fails.  It could even
short-circuit all other configure link tests, such that one might be
able to configure a package containing link tests for a system that
doesn't really support linking.  The reason to not have this behavior
enabled by default is that we do want to detect situations when the
compiler is broken (the number of bogus reports caused by them used to
be huge when we didn't do it), but if a standard configure argument
disables the test, I think we're kind of ok.

Thoughts?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer