Please use the gcc-help mailing list for discussing using and building GCC, rather than this list. Please take any follow up there, thanks.
On 23 January 2013 08:25, Alec Teal wrote: > On 23/01/13 08:19, Alec Teal wrote: >> >> On 23/01/13 08:16, Alec Teal wrote: >>> >>> configure went well but I keep hitting: >>> >>> ../.././gcc/gengtype.c:963: error: undefined reference to 'lexer_line' >>> ../.././gcc/gengtype.c:1098: error: undefined reference to 'lexer_line' >>> ../.././gcc/gengtype.c:1154: error: undefined reference to 'lexer_line' >>> ../.././gcc/gengtype.c:1164: error: undefined reference to 'lexer_line' >>> ../.././gcc/gengtype-parse.c:53: error: undefined reference to >>> 'yylex(char const**)' >>> ../.././gcc/gengtype-parse.c:1044: error: undefined reference to >>> 'yybegin(char const*)' >>> ../.././gcc/gengtype-parse.c:1070: error: undefined reference to >>> 'lexer_toplevel_done' >>> ../.././gcc/gengtype-parse.c:1075: error: undefined reference to >>> 'yyend()' >>> >>> I've installed flex, bison and yacc (should it use it, it seems to be >>> using bison -y) (if I hadn't have installed flex would it's "missing" ones >>> have worked? >>> >>> What's wrong? It does configure fine! I'm not sure what you're asking. I assume those errors were *before* you installed flex? To build from source you need flex, as documented at http://gcc.gnu.org/install/prerequisites.html The configure script doesn't check for it because it's only needed when building from subversion or source snapshots. For packaged releases the files generated by flex are included in the tarball and flex is not required, so configure should not fail if users don't have it. We could make configure only require it for source snapshots, and generate a different configure for release tarballs, but that would be an extra maintenance burden and we'd probably accidentally end up with a release that checked for flex when it shouldn't. Instead we just require those working with development sources to install flex if building from source and it works. >> checking for version 0.11 of ISL... no >> The following languages will be built: c,c++,fortran,java,lto,objc >> *** This configuration is not supported in the following subdirectories: >> gnattools target-libada target-libgo target-libbacktrace >> (Any other directories should still work fine.) >> checking for default BUILD_CONFIG... bootstrap-debug >> *** removing build-x86_64-unknown-linux-gnu/libiberty/Makefile to force >> reconfigure >> *** removing build-x86_64-unknown-linux-gnu/fixincludes/Makefile to force >> reconfigure >> >> >> Noticed this in the config output, should this really be silent? I think this comes from autotools boilerplate stuff. > /sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/libisl.so.8.0.0-gdb.py is not > an ELF file - it has the wrong magic bytes at the start. > > > cannot fix this, even running it directly python has no module "gdb", is > this the source? Ignore the warning. The file contains python pretty printers which are autoloaded by gdb when /usr/lib/x86_64-linux-gnu/libisl.so.8.0.0 is loaded, as such it has to be in the same directory as the shared lib, but that means ldconfig tries to process it and fails. The warning is harmless. There's a bugzilla report somewhere about warnings about the similar libstdc++.so.6.0.16-gdb.py file, but doing anything about it is non-trivial and low priority.
