I found some old bugs for this issue, they're all resolved, fixed and so on, but I still have this issue. I get this every time I try to compile a hello world program: cd '/home/shadowlord/TEMP2' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake -f Makefile.cvs && cd '/home/shadowlord/TEMP2/debug' && CXXFLAGS="-O0 -g3" "/home/shadowlord/TEMP2/configure" --enable-debug=full && cd '/home/shadowlord/TEMP2/debug' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake -k aclocal /usr/share/aclocal/gtkgl.m4:4: warning: underquoted definition of AM_PATH_GTKGL /usr/share/aclocal/gtkgl.m4:4: run info '(automake)Extending aclocal' /usr/share/aclocal/gtkgl.m4:4: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal autoheader automake autoconf installing -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... 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++... gcc3 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 for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... /usr/i586-pc-linux-gnu/bin/ld checking if the linker (/usr/i586-pc-linux-gnu/bin/ld) is GNU ld... yes checking for /usr/i586-pc-linux-gnu/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 recognize dependent libraries... pass_all checking how to run the C preprocessor... gcc -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 how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... gfortran checking whether we are using the GNU Fortran 77 compiler... yes checking whether gfortran accepts -g... yes checking the maximum length of command line arguments... 98304 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for correct ltmain.sh version... no configure: error: *** [Gentoo] sanity check failed! *** *** libtool.m4 and ltmain.sh have a version mismatch! *** *** (libtool.m4 = 1.5.24, ltmain.sh = 1.5a) *** Please run: libtoolize --copy --force if appropriate, please contact the maintainer of this package (or your distribution) for help. *** Exited with status: 1 *** Actually I can hack ltmain.sh, but I have to do it with each new project, because kdevelop generates a wrong ltmain.sh for each project. Reproducible: Always Steps to Reproduce: 1. Create a new C++ project 2. Select C++ hello world app 3. Try to build it Actual Results: The above message Expected Results: Well I expected it to compile :) Kdevelop 3.4.1, compiled for Pentium4
They are resolved UPSTREAM [1] and nothing changed wrt this. Nothing we could do here. No need to file duplicates, sorry. [1] http://bugs.gentoo.org/page.cgi?id=fields.html#resolution *** This bug has been marked as a duplicate of bug 97600 ***
You mean I can't use Kdevelop as intended until the next or next-next Kdevelop/Gentoo release? :(
See bug 97600, Comment #9. Not a Gentoo bug, sorry.
And they say that it's not a KDE bug either so I don't know where to submit it :) well, I understand what you mean. Thanks anyway.
