autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 01-ac-lang-compiler-require.patch (Was: CC/CPP/TRY_LINK)


From: Ralf Corsepius
Subject: Re: 01-ac-lang-compiler-require.patch (Was: CC/CPP/TRY_LINK)
Date: Wed, 08 Nov 2000 11:58:32 +0100

Akim Demaille wrote:
> 
> Thanks for the report, it's a known bug.  In fact this bug is not new,
> what is new is that the core machinery now correctly catches it.

With your patch, it seems to be hidden, but present, again.

I.e. your patch solves part of the problem, but another one remains.
 
> The problem is related to the fact that AC_PROG_CC can be expanded
> twice, and since the first expansion expands AC_PROG_CPP, the second
> expansion of AC_PROG_CC will complain because AC_PROG_CPP was run
> beforehand.
> 
> The following patch fixes this issue.  There was another obvious
> implementation possibility: having AC_LANG_COMPILER(C) provide
> AC_PROG_CC, but I think this approach is better.
> 

I can't judge :)

The situation appears to have improved, but here remains another,
probably related problem w/ cvs-autoconf:

1. Explicit PROG_[CC|CPP] in configure.in:

# cat configure.in
AC_INIT(hello.c)
AM_INIT_AUTOMAKE(foo,1,no)
AC_PROG_CC
AC_PROG_CPP
AC_OUTPUT(Makefile)
# ./configure
..
checking for gcc... gcc
..
checking how to run the C preprocessor... gcc -E
checking dependency style of gcc... none
checking how to run the C preprocessor... gcc -E
..
=> CPP being checked twice, but in correct order. AFAIU, this is
what you are referring to, above.

2. PROG_[CC|CPP] in external m4-file:

# cat configure.in
AC_INIT(hello.c)
AM_INIT_AUTOMAKE(foo,2,no)
MY_PROG_CC
AC_OUTPUT(Makefile)
# cat acinclude.m4
AC_DEFUN([MY_PROG_CC],
[
AC_PROG_CC
AC_PROG_CPP
])
# ./configure
..
checking how to run the C preprocessor... cc -E
checking for gcc... gcc
..
checking dependency style of gcc... gcc
checking how to run the C preprocessor... cc -E
..
=> CPP being checked twice, but now the order gets swapped - Ouch :(


Though this might seem to be a minor problem at first glance, but
this is pretty devastating wrt. cross-compilation:

Example 1b:
./configure --build=`config.guess` --host=sh-rtems
..
checking for sh-rtems-gcc... sh-rtems-gcc
..
checking how to run the C preprocessor... sh-rtems-gcc -E
checking dependency style of sh-rtems-gcc... none
checking how to run the C preprocessor... sh-rtems-gcc -E
..
=> Correct cpp being picked up

Example 2b:
./configure --build=`config.guess` --host=sh-rtems
..
checking how to run the C preprocessor... cc -E
checking for sh-rtems-gcc... sh-rtems-gcc
..
checking dependency style of sh-rtems-gcc... gcc
checking how to run the C preprocessor... cc -E
..
=> Wrong cpp being picked up.

Bummer :)

[Using CVS automake and CVS autoconf w/ Akims patch]

Ralf

-- 
Ralf Corsepius 
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
mailto:address@hidden           FAX: +49/731/501-999  
http://www.faw.uni-ulm.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]