Re: [RFC] Update to current automake/autoconf/libtool versions.

[Geoff Keating <geoffk@geoffk.org>]

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.

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.

-- 
- Geoffrey Keating <geoffk@geoffk.org>