AC_NO_EXECUTABLES in libc/machine/sh

[Jeff Johnston]

DJ Delorie wrote:
> With the 2.13->2.59 change, it seems that sh-elf has broken as gcc is
> trying to do a test compile in libc/machine/sh to satisfy
> prerequisites for AC_EGREP_CPP.  Of course that fails as we're still
> building the C library.  A simple addition of AC_NO_EXECUTABLES seems
> to get around that.  However, in a local discussion, one of us also
> noted that the objects in that directory don't seem to be correctly
> overriding the generic C implementations of those functions, due to
> new object naming conventions.  We're not sure what to do about that.
> Furthermore, another one of us noted that the AC_NO_EXECUTABLES macro
> is not documented in autoconf, so we're not even sure this is the
> right fix.  Also, perhaps this macro should go in a common file?
> Anyway, comments welcome.
>

In doing the transformation, I remember trying AC_NO_EXECUTABLES and 
running into problems.  It might have been when I was building for 
x86-linux which uses libtool, but I can't remember exactly what the 
problem was being that it was so many iterations ago.  It also could 
easily have been caused by a screw-up on my part in the early parts of 
the transformation work.

The top-level acinclude.m4 defines the LIB_AC_PROG_CC and LIB_AM_PROG_AS 
macros which are meant to be used to avoid the executable tests.  I was 
not aware that sh was bringing in AC_EGREP_CPP.  That said, I believe 
this to be isolated to sh and your fix is fine.  Feel free to check it in.

Regarding the use of the macro, I found the following comment for it:

# AC_NO_EXECUTABLES
# -----------------
# FIXME: The GCC team has specific needs which the current Autoconf
# framework cannot solve elegantly.  This macro implements a dirty
# hack until Autoconf is able to provide the services its users
# need.
#
# Several of the support libraries that are often built with GCC can't
# assume the tool-chain is already capable of linking a program: the
# compiler often expects to be able to link with some of such
# libraries.
#
# In several of these libraries, workarounds have been introduced to
# avoid the AC_PROG_CC_WORKS test, that would just abort their
# configuration.  The introduction of AC_EXEEXT, enabled either by
# libtool or by CVS autoconf, have just made matters worse.
#
# Unlike an earlier version of this macro, using AC_NO_EXECUTABLES does
# not disable link tests at autoconf time, but at configure time.
# This allows AC_NO_EXECUTABLES to be invoked conditionally.

-- Jeff J.

> 	* libc/machine/sh/configure.in: Avoid link tests.
> 	* libc/machine/sh/configure: Regenerate.
> 
> Index: configure.in
> ===================================================================
> RCS file: /cvs/src/src/newlib/libc/machine/sh/configure.in,v
> retrieving revision 1.3
> diff -p -U3 -r1.3  configure.in
> --- configure.in	13 Apr 2006 19:56:26 -0000	1.3
> +++ configure.in	24 Apr 2006 18:33:42 -0000
> @@ -10,6 +10,8 @@ AC_CONFIG_AUX_DIR(../../../..)
>  
>  NEWLIB_CONFIGURE(../../..)
>  
> +AC_NO_EXECUTABLES
> +
>  AC_EGREP_CPP([sh5], [
>  #if __SH5__
>    sh5