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, work-arounds 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.
After some discussion in the gcc-patches mailing list, and some
additional issues I've just thought of, I'm proposing something like
this for such libraries:
ifndef([AC_NO_EXECUTABLES],[
AC_DEFUN([AC_NO_EXECUTABLES],[
AC_BEFORE([AC_NO_EXECUTABLES],[AC_PROG_CC_WORKS])
AC_BEFORE([AC_NO_EXECUTABLES],[AC_EXEEXT])
AC_BEFORE([AC_NO_EXECUTABLES],[AC_TRY_LINK])
AC_DEFUN([AC_PROG_CC_WORKS],[cross_compiling=untested])
AC_DEFUN([AC_EXEEXT],[EXEEXT=])
AC_DEFUN([AC_TRY_LINK],[m4_error([Cannot perform link tests])])
])
])
Now we (the GCC folks) has two problems. We'd like to have this
supported by the next release of autoconf and we'd like to be able to
disable linking tests on a per-language basis. For example, we may be
unable to do linking tests while compiling the C support libraries,
but, after this is done, we might use C linking tests while
configuring the C++ libraries.
Any ideas about how to selectively disable AC_TRY_LINK, to use in
AC_NO_CXX_EXECUTABLES? Any suggestions about naming conventions for
these macros?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
