This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: AC_NO_EXECUTABLES in libc/machine/sh
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: newlib at sourceware dot org
- Date: Mon, 24 Apr 2006 15:21:32 -0400
- Subject: Re: AC_NO_EXECUTABLES in libc/machine/sh
- References: <200604241845.k3OIjDgl032022@greed.delorie.com>
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