Desc: If AC_PROG_CXX finds a C++ compiler, it returns the full path. This breaks AC_PATH_PROG. Commit: https://git.claws-mail.org/?p=claws.git;a=commit;h=b38631b3badc0e7509994e7631a454309dcb1f44 My autoconf: 2.69 automake 1.16.2 Kernel 5.10.8 GLIB-2.0 = 2.66 Claws-Mail = 3.17.8 This section of configure.ac always fails: AC_PROG_CXX AC_PATH_PROG(REAL_CXX, $CXX) HAVE_CXX=no if test -n "$REAL_CXX"; then HAVE_CXX=yes fi Because AC_PATH_PROG just wants a program name, not a path and program name, HAVE_CXX will always be `no' and liteHTML will never be built. Here is configure output for the section shown above. The last line shows the fail. checking whether we are using the GNU C++ compiler... yes checking whether /usr/bin/g++ accepts -g... yes checking dependency style of /usr/bin/g++... gcc3 checking how to run the C++ preprocessor... /usr/bin/g++ -E checking for ld used by /usr/bin/g++... /usr/bin/ld -m elf_x86_64 checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes checking whether the /usr/bin/g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking for /usr/bin/g++ option to produce PIC... -fPIC -DPIC checking if /usr/bin/g++ PIC flag -fPIC -DPIC works... yes checking if /usr/bin/g++ static flag -static works... yes checking if /usr/bin/g++ supports -c -o file.o... yes checking if /usr/bin/g++ supports -c -o file.o... (cached) yes checking whether the /usr/bin/g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for /usr/bin/g++... no I tried to figure out an alternative, but could not. I'm not sure this test is necessary because AC_PROG_CXX is robust. Maybe even it's a bug in autotools. Stripping the path from CXX variable, the result is: checking for g++... /usr/bin/g++ and litehtml is built. If there was a way to parse out the path from the C++ command, this would work. Perhaps something with m4_esyscmd and `cut'??
Works for me, and presumably most other people: checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for ld used by g++... /usr/bin/ld -m elf_x86_64 checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC -DPIC checking if g++ PIC flag -fPIC -DPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for g++... /usr/bin/g++ same autoconf and automake versions. Is there something else that you not telling?
Thank you. It appears, that my build script is the culprit. I preset variables with the full path of compilers through `which`. CXXFLAGS="$CFLAGS" CC=`which gcc` CPP="$CC -E" CXX=`which g++` CXXCPP="$CXX -E" When running at the command prompt, ./autogen.sh is fine. These environment variables are not set. This is an error of my own making. Sorry to trouble. Please close as NOTABUG.
CLOSE: NOTABUG