Under heading "GCC Stage 2 (All frontends)", the commands show "./configure" which does an in-tree build of gcc. gcc needs to be built in a separate directory. The "GCC Stage 1" instructions higher up the page are better. Reproducible: Always Steps to Reproduce: 1. Run the commands listed in the Embedded Handbook, chapter 2, for manually building a cross toolchain Actual Results: Some error building mdeps file (no make rule) in the libgcc Expected Results: Cross-compiler builds successfully
Can you please attach the output of the failing command?
Here is the end of the build output: Checking multilib configuration for libgcc... make[2]: Entering directory `/usr/src/nios2/gcc-4.4.4/nios2-linux-uclibc/libgcc' Makefile:143: ../.././gcc/libgcc.mvars: No such file or directory make[2]: *** No rule to make target `../.././gcc/libgcc.mvars'. Stop. make[2]: Leaving directory `/usr/src/nios2/gcc-4.4.4/nios2-linux-uclibc/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/usr/src/nios2/gcc-4.4.4' make: *** [all] Error 2 This is a well-known problem with building in the source directory, see gcc bug 32212. gcc upstream only supports using a build directory, not an in-tree build. The Embedded Handbook (see linked bug repro URL) gives the wrong build recipe.
there is absolutely no support for what you're trying to do. the handbook makes it pretty damn clear that you're 100% on your own if you attempt to do this. the bug you're hitting is a problem with the source code you have, pure and simple.
If the Embedded Handbook isn't intended to be helpful, maybe the whole section on manually building the toolchain should be deleted. But the change I'm suggesting is - trivial - clearly correct Compare code listing 3.10 and 3.14. Notice that 3.10 says "cd build; ../configure", which is correct according to upstream. That's missing from 3.14. All I'm asking is that the one extra line "cd build" and one extra dot to change "./configure" into "../configure" be added to code listing 3.14.
Did anyone even bother to read the GCC bug report I mentioned? Direct link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32212
that gcc PR is irrelevant. there is a bug in the gcc code and it should be fixed. you should also try reading the big fat red warning blocks in the handbook page you keep referring to.
