[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?