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 <[EMAIL PROTECTED]> 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 _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool