Re: mips64

[Kai Ruottu <kai dot ruottu at wippies dot com>]

Erik Peterson wrote:

> I am currently attempting to cross compile gcc-4.2.2 for 
> mips64-octeon-linux-gnu on an i686 linux box.
>
> I would like to use the resulting compiler natively on the mips target.  
> I have configured with the following  :
>
> ./configure --host=mips64-octeon-linux-gnu 
> --prefix=/opt/OCTEON-SDK/mocana/tools/gcc-3.4.0/target
> --enable-languages=c --target=mips64-octeon-linux-gnu

A native GCC ($host=$target) usually uses '--prefix=/usr'...

> My questions are:
>
> What is genmodes and should it be cross compiled?  It looks like the 
> build system is trying to invoke it on the host it was cross compiled.

Quite a lot 'gen*' executables will be produced for the $build system
and run there during the GCC build. So this is fully normal. These will
mainly handle the 'gcc/config/<cpu>/*.md' "machine description" and
"gen"erate source files from them, these then being compiled for the
$host system...

> Is it feasible to build it myself natively and patch up the makefile.in 
> or am I clearly doing something wrong here?

Needing to patch the Makefile.in's is not normal...

> One note:  I did have to manually change some of the configure scripts from
>
> cross_compiling=no
> to
> cross_compiling=yes
>
> Could this be a problem?

I myself have always told also the '--build=$build', in your case this
being '--build=i686-linux-gnu', to the GCC 'configure'. If you really
configured in the main source directory, your "./configure" hints this,
not in a separate build directory outside the GCC sources, then this is
a problem, the GCC build instructions definitely tell that this
shouldn't be done!

A "build" subdirectory in the 'gcc-4.2.2' sources should however be ok,
generally the configure process shouldn't care about where this separate
directory is as long as it is NOT one of the original source directories
and has not any special meaning for its name. For instance using a
'newlib', 'libgloss', 'gas', 'ld', 'yacc', 'bison' etc as the "build"
directory name would cause special configure and build operations being
tried there.. But the 'build' itself and its translations to other
languages like 'bygga' (in swedish) and 'bauen' (in german) would be
ok...  I myself have never had any problems with the 'build' directory
name. Generally if one has 10 or more GCC sources, binutils, GDB/Insight
etc sources in a '.../src', then using a separate build dir for each
source package would duplicate the amount of the directories. Ok, using
a '.../build/<the_package>', for instance a '/home/build/gcc-4.2.2' if
the sources are in '/home/src/gcc-4.2.2', could make some order for the
possible enthropy mess (the disorder increases and all the empty space
will be filled)... But I once choosed to use this 'build' subdir, for
instance 'gcc-4.2.2/build' in the gcc-4.2.2 sources case and changing
my habits isn't that easy... :(

The "official" words in 'gcc.gnu.org', "Manuals/Install" are :

"First, we highly recommend that GCC be built into a separate directory 
than the sources which does not reside within the source tree. This is 
how we generally build GCC; building where srcdir == objdir should still 
work, but doesn't get extensive testing; building where objdir is a 
subdirectory of srcdir is unsupported."

But generally the idea about the GCC configure/build process going to
the parent directory of the $BUILD one and then doing weird things in
it or in its other subdirectories, is quite odd... In those
Cygnus/RedHat "combined source tree" sources there was those 'src' and
'build' subdirs in something like 'gnupro-20060707' "sources". If the
previous clause is true, then also the combined tree arrangement clashed
against it, the two directories were parts of the "GNU sources" and one
shouldn't configure inside them...