automake
[Top][All Lists]
Advanced

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

Re: /lib/cpp again


From: Akim Demaille
Subject: Re: /lib/cpp again
Date: 05 Jul 2001 19:39:53 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor)

| >>>>> "Akim" == Akim Demaille <address@hidden> writes:
| 
| Akim> The problem is right here: for whatever reason (I'm tracking
| Akim> now), the C preproc is looked for _before_ the C compiler.
| Akim> AC_REQUIRE should guarantee it does not apply.
| 
| Akim> I don't know what's responsible for this, but that's the
| Akim> culprit.
| 
| I have no idea how to solve this, but (it had to happen...) it's
| because of Automake's redefinition of AC_PROG_CC.  All the m4_require
| mechanism must wrap the actual definition of the macro, and with:
| 
| # AM_INIT_AUTOMAKE(PACKAGE,VERSION, [NO-DEFINE])
| # ----------------------------------------------
| ...
| AC_PROVIDE_IFELSE([AC_PROG_][CC],
|                   [AM_DEPENDENCIES(CC)],
|                   [define([AC_PROG_][CC],
|                           defn([AC_PROG_][CC])[AM_DEPENDENCIES(CC)])])dnl
| 
| 
| you end up breaking the diversion mechanism :(

So, it seems to me we are facing the following problem:

AC_PROG_CC is defined by Autoconf as 

        AC_PROG_CC_PRO . AC_PROG_CC_BODY . AC_PROG_CC_EPI

where _PRO sets up the REQUIRE mechanism, _EPI closes it, and provides
AC_PROG_CC (i.e., says `OK, it has been run').

Then Automake redefines it as

        AC_PROG_CC_PRO . AC_PROG_CC_BODY . AC_PROG_CC_EPI . AM_DEP(CC)

and AM_DEP(CC) REQUIRES AC_PROG_CC

Which is of course very wrong as it's expected to be part of
AC_PROG_CC: AC_PROG_CC requires AM_DEP(CC) which requires AC_PROG_CC.

Had the EPI been correctly placed, i.e., if we had

        AC_PROG_CC_PRO . AC_PROG_CC_BODY . AM_DEP(CC) . AC_PROG_CC_EPI

the problem would have been caught.




Anyway, it seems to me that the answer is that AM_DEPENDENCIES must
*not* AC_REQUIRE AC_PROG_CC nor AC_PROG_CXX.


/tmp/hello-test % diff aclocal.m4 aclocal.new -u                 nostromo Err 1
--- aclocal.m4  Wed Jul  4 11:20:10 2001
+++ aclocal.new Thu Jul  5 19:36:32 2001
@@ -241,13 +241,10 @@
 AC_REQUIRE([AM_OUTPUT_DEPENDENCY_COMMANDS])dnl
 am_compiler_list=
 ifelse([$1], CC,
-       [AC_REQUIRE([AC_PROG_][CC])dnl
-AC_REQUIRE([AC_PROG_][CPP])
-depcc="$CC"
+       [depcc="$CC"
 depcpp="$CPP"],
-       [$1], CXX, [AC_REQUIRE([AC_PROG_][CXX])dnl
-AC_REQUIRE([AC_PROG_][CXXCPP])
-depcc="$CXX"
+       [$1], CXX,
+       [depcc="$CXX"
 depcpp="$CXXCPP"],
        [$1], OBJC, [am_compiler_list='gcc3 gcc'
 depcc="$OBJC"



And then you get:

  | /tmp/hello-test % cp aclocal.new aclocal.m4
  | /tmp/hello-test % ace
  | ./configure
  | /tmp/hello-test % ./configure
  | checking for a BSD compatible install... /usr/bin/install -c
  | checking whether build environment is sane... yes
  | checking for mawk... mawk
  | checking whether make sets ${MAKE}... yes
  | checking for g++... g++
  | checking for C++ compiler default output... a.out
  | checking whether the C++ compiler works... yes
  | checking whether we are cross compiling... no
  | checking for executable suffix... 
  | checking for object suffix... o
  | checking whether we are using the GNU C++ compiler... yes
  | checking whether g++ accepts -g... yes
  | checking for style of include used by make... GNU
  | checking dependency style of g++... gcc
  | checking build system type... i686-pc-linux-gnu
  | checking host system type... i686-pc-linux-gnu
=>| checking for gcc... gcc
=>| checking whether we are using the GNU C compiler... yes
=>| checking whether gcc accepts -g... yes
  | checking dependency style of gcc... gcc
  | checking for ld used by GCC... /usr/bin/ld
  | checking if the linker (/usr/bin/ld) is GNU ld... yes
  | checking for /usr/bin/ld option to reload object files... -r
  | checking for BSD-compatible nm... /usr/bin/nm -B
  | checking whether ln -s works... yes
  | checking how to recognise dependant libraries... pass_all
  | checking command to parse /usr/bin/nm -B output... ok
=>| checking how to run the C preprocessor... gcc -E
  | checking for dlfcn.h... yes
  | checking for ranlib... ranlib
  | checking for strip... strip
  | checking for objdir... .libs
  | checking for gcc option to produce PIC... -fPIC
  | checking if gcc PIC flag -fPIC works... yes
  | checking if gcc static flag -static works... yes
  | checking if gcc supports -c -o file.o... yes
  | checking if gcc supports -c -o file.lo... 
  | checking if gcc supports -fno-rtti -fno-exceptions... yes
  | checking whether the linker (/usr/bin/ld) supports shared libraries... yes
  | checking how to hardcode library paths into programs... immediate
  | checking whether stripping libraries is possible... yes
  | checking dynamic linker characteristics... GNU/Linux ld.so
  | checking if libtool supports shared libraries... yes
  | checking whether -lc should be explicitly linked in... no
  | creating libtool
  | configure: creating ./config.status
  | config.status: creating Makefile



Could you confirm you no longer have the problem?

Tom, any actual reason for AM_DEPENDENCIES to require the compiler?



reply via email to

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