libtool 1.5 C++ issues, rehash

[Daniel Reed]

configure.in:
  ...
 echo ""
 echo ""
 echo "Configuring libtool"
 echo ""
 AC_LIBLTDL_CONVENIENCE
 AC_LIBTOOL_DLOPEN
 AC_PROG_LIBTOOL

./configure:
  ...


 Configuring libtool

 checking for a sed that does not truncate output... /usr/bin/sed
 checking for egrep... grep -E
 checking for ld used by gcc... /bin/ld
 checking if the linker (/bin/ld) is GNU ld... yes
 checking for /bin/ld option to reload object files... -r
 checking for BSD-compatible nm... /bin/nm -B
 checking whether ln -s works... yes
 checking how to recognise dependent libraries... pass_all
 checking for ANSI C header files... yes
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
 checking for stdlib.h... yes
 checking for string.h... yes
 checking for memory.h... yes
 checking for strings.h... yes
 checking for inttypes.h... yes
 checking for stdint.h... yes
 checking for unistd.h... yes
 checking dlfcn.h usability... yes
 checking dlfcn.h presence... yes
 checking for dlfcn.h... yes
 checking for g++... no
 checking for c++... no
 checking for gpp... no
 checking for aCC... no
 checking for CC... no
 checking for cxx... no
 checking for cc++... no
 checking for cl... no
 checking for FCC... no
 checking for KCC... no
 checking for RCC... no
 checking for xlC_r... no
 checking for xlC... no
 checking whether we are using the GNU C++ compiler... no
 checking whether g++ accepts -g... no
 checking dependency style of g++... none
 checking how to run the C++ preprocessor... /lib/cpp
 configure: error: C++ preprocessor "/lib/cpp" fails sanity check
 See `config.log' for more details.

config.log:
 configure:5177: /lib/cpp -I/software/linux/linux-2.4.20/dist/include 
-I/software/ncurses/ncurses-5.3/dist/include conftest.cc
 cpp: conftest.cc: C++ compiler not installed on this system


I do not have a C++ compiler on this system, so that error is that is
correct. However, my code is not written in C++, and I do not believe
anything in my configure.in should be adding in a dependency. Previous
versions of libtool's .m4 scripts did not add any checks for C++.

Looking through Google I seem to find references to this dated from April,
and discussion until early June, but no resolution. I just upgraded from
libtool-1.4.3 to libtool-1.5 today in order to get a working
AC_LIBTOOL_DLOPEN (the patches I found on Google didn't seem to work, and
I'd rather upgrade anyway). I have tried replacing the libtool.m4 and
ltdl.m4 files with the ones in ftp://alpha.gnu.org/gnu/cvs/libtool.tgz,
regenerated acinclude.m4 and aclocal.m4, same effect (the output above is
actually using the CVS .m4's). I've also tried setting CXX=no just before
calling AC_PROG_LIBTOOL, and the actual error persists (though the 15 search
lines for a C++ compiler disappear). In 1.4.3, ./configure never attempted
to do anything with C++ using the same configure.in, and unfortunately I
don't know m4 well enough to figure out what's causing the improper
dependency.


Original ./configure (from 1.4.3):
  ...


 Configuring libtool

 checking for ld used by GCC... /bin/ld
 checking if the linker (/bin/ld) is GNU ld... yes
 checking for /bin/ld option to reload object files... -r
 checking for BSD-compatible nm... /bin/nm -B
 checking for a sed that does not truncate output... /usr/bin/sed
 checking whether ln -s works... yes
 checking how to recognise dependent libraries... pass_all
 checking command to parse /bin/nm -B output... ok
 checking for egrep... grep -E
 checking for ANSI C header files... yes
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
 checking for stdlib.h... yes
 checking for string.h... yes
 checking for memory.h... yes
 checking for strings.h... yes
 checking for inttypes.h... yes
 checking for stdint.h... yes
 checking for unistd.h... yes
 checking dlfcn.h usability... yes
 checking dlfcn.h presence... yes
 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... yes
 checking if gcc supports -fno-rtti -fno-exceptions... no
 checking whether the linker (/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 to build shared libraries... yes
 checking whether to build static libraries... yes
 checking whether -lc should be explicitly linked in... no
 creating libtool


Does anyone have a {libtool.m4,ltdl.m4} pair that has a working
AC_LIBTOOL_DLOPEN and does not introduce the C++ dependency?

-- 
Daniel Reed <address@hidden>    http://shell.n.ml.org/n/
It is a miracle that curiosity survives formal education -- Albert Einstein
http://site.n.ml.org/download/20030626225106/naim/naim-0.11.6-2003-06-25-0249.tar.gz