An old question:gcc and arm-linux-gcc?

In fact you do need a tool chain. see:
http://www.uclinux.org

-Michael

Really?  You've got a copy of gcc that accepts either arm or
i386?  What happens when you try that?



Each build of gcc only supports one family of processors (IA32
is one family, ARM is another).  You can use -mcu to select
which member of the family to generate code for, but it's not
possible to build gcc with support for multiple cpu families at
the same time.

You need one build of gcc for IA32 processors (i386, Pentium,
Athlon, etc.), and a different one for ARM processors (arm7,
arm9, arm11, etc.).

Thank you very much!!

When I read the manual of the GNU assembler as, and I find that gas
has option of
"
[ -m[arm]1 | -m[arm]2 | -m[arm]250 | -m[arm]3 | -m[arm]6 | -m[arm]7[t]
[[d]m[i]] ]
[ -m[arm]v2 | -m[arm]v2a | -m[arm]v3 | -m[arm]v3m | -m[arm]v4 | -m[arm]
v4t ]
"
and
"
-m68000 | -m68008 | -m68010 | -m68020 | -m68030 | -m68040 | -m68060
| -m68302 | -m68331 | -m68332 | -m68333 | -m68340 | -mcpu32 | -m5200
"
, and so on. That is my question!

On 1D4%C231C8%D5, CF%C2CE%E710CA%B122B7%D6, Grant Edwards <gra...@vis=
i.com> wrote:

Its the same with gas. All parts of your toolchain are built for one
architecture.

For example here I'm using different toolchains for various targets:

$ ls arm-v5-toolchain
arm-v5te-linux-gnueabi-addr2line  arm-v5te-linux-gnueabi-gccbug  
arm-v5te-linux-gnueabi-ranlib     arm-v5te-linux-gnueabi-ar        
arm-v5te-linux-gnueabi-gcov       arm-v5te-linux-gnueabi-readelf
arm-v5te-linux-gnueabi-as         arm-v5te-linux-gnueabi-gdb    
arm-v5te-linux-gnueabi-run        arm-v5te-linux-gnueabi-c++      
arm-v5te-linux-gnueabi-gdbtui     arm-v5te-linux-gnueabi-size
arm-v5te-linux-gnueabi-c++filt    arm-v5te-linux-gnueabi-gprof  
arm-v5te-linux-gnueabi-strings    arm-v5te-linux-gnueabi-cpp      
arm-v5te-linux-gnueabi-ld         arm-v5te-linux-gnueabi-strip
arm-v5te-linux-gnueabi-g++        arm-v5te-linux-gnueabi-nm
arm-v5te-linux-gnueabi-gcc        arm-v5te-linux-gnueabi-objcopy
arm-v5te-linux-gnueabi-gcc-4.3.2  arm-v5te-linux-gnueabi-objdump

$ ls arm-v6-toolchain
arm-1136jfs-linux-gnueabi-addr2line  arm-1136jfs-linux-gnueabi-gprof
arm-1136jfs-linux-gnueabi-ar         arm-1136jfs-linux-gnueabi-ld
arm-1136jfs-linux-gnueabi-as         arm-1136jfs-linux-gnueabi-nm
arm-1136jfs-linux-gnueabi-c++        arm-1136jfs-linux-gnueabi-objcopy
arm-1136jfs-linux-gnueabi-c++filt    arm-1136jfs-linux-gnueabi-objdump
arm-1136jfs-linux-gnueabi-cpp        arm-1136jfs-linux-gnueabi-ranlib
arm-1136jfs-linux-gnueabi-g++        arm-1136jfs-linux-gnueabi-readelf
arm-1136jfs-linux-gnueabi-gcc        arm-1136jfs-linux-gnueabi-run
arm-1136jfs-linux-gnueabi-gcc-4.3.2  arm-1136jfs-linux-gnueabi-size
arm-1136jfs-linux-gnueabi-gccbug     arm-1136jfs-linux-gnueabi-strings
arm-1136jfs-linux-gnueabi-gcov       arm-1136jfs-linux-gnueabi-strip
arm-1136jfs-linux-gnueabi-gdb        arm-1136jfs-linux-gnueabi-gdbtui

$ ls powerpc
powerpc-603e-linux-gnu-addr2line  powerpc-603e-linux-gnu-gcc-4.3.2
powerpc-603e-linux-gnu-objdump    powerpc-603e-linux-gnu-ar        
powerpc-603e-linux-gnu-gccbug     powerpc-603e-linux-gnu-ranlib
powerpc-603e-linux-gnu-as         powerpc-603e-linux-gnu-gcov      
powerpc-603e-linux-gnu-readelf    powerpc-603e-linux-gnu-c++      
powerpc-603e-linux-gnu-gdb        powerpc-603e-linux-gnu-run
powerpc-603e-linux-gnu-c++filt    powerpc-603e-linux-gnu-gdbtui    
powerpc-603e-linux-gnu-size       powerpc-603e-linux-gnu-cpp      
powerpc-603e-linux-gnu-gprof      powerpc-603e-linux-gnu-strings
powerpc-603e-linux-gnu-embedspu   powerpc-603e-linux-gnu-ld        
powerpc-603e-linux-gnu-strip      powerpc-603e-linux-gnu-g++      
powerpc-603e-linux-gnu-nm         powerpc-603e-linux-gnu-gcc      
powerpc-603e-linux-gnu-objcopy

(and so on for x86...)

It makes sense to name the toolchain in this way. The autotools are using
parts of the names to guess for what kind of architecture a program should
be built.

jbe

-m[arm]7[t][[d]m[i]] ]

| -m68331 | -m68332 | -m68333 | -m68340 | -mcpu32 | -m5200


That wasn't a question.  That was a statement.

Have you _tried_ any of those options?

Here's what happens when you try them using an IA32 build of
"as":

$ as --version
GNU assembler (GNU Binutils) 2.18
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under
the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of i486-pc-linux-gnu'.

$ as -marmv4 foo.s
as: unrecognized option -marmv4'

$ as -m68331
as: unrecognized option -m68331'

Like I and others have already told you: when you build
binutils or gcc, you have to configure it for _one_
architecture.

If you need to write code for three different architectures,
you have to build three different toolchains.

Thank you very much !!A3%A1

I have not compile gcc!

I see! Before compile gcc, you should config it for one architecture.
And it may build a version for i386, That only compile i386 program.
But the manual is for all architecture supported!

Am I right?


On 2D4%C23C8%D5, C9%CFCE%E712CA%B151B7%D6, Grant Edwards <gra...@visi=
.com> wrote:

Yes!!! You are right !!!

Now sit down, take a deep breath, and relax - there's no need for all
these exclamation marks.

Once you have figured out what platform you are running on, and what
devices you are targeting, you can start searching for pre-built
binaries if you don't want to configure and compile gcc (and related
tools) yourself.

Thanks all of you!

When I find the truth of this question, I have lots of fun. I come
from China, and I am an English Beginer. So .......

Thanks!

On 2E6%9C88%3E6%97A5%, E4%B88B%E58D%887E6%97B6%50E5%8886%, David Bro=
wrote:

You need to have somewhere the components of
an arm-linux toolchain installed, so gcc can
use them.

The gcc is only a program caller which calls
the following pieces of software:

  - cpp
  - cc1
  - as
  - ld

cpp does the pre-processing of the # -directives,
cc1 turns expanded C code into assembly language,
as translates the assembly language into relocatable
object files and ld glues together the executable
file from the translated object files and library files.

cc1, as and ld have to be generated for the correct
processor architecture: i386+ translators are different
from m68k translators and different from ARM translators.
(Of course, the same applies to other arcitectures
supported by the GNU translator suite).

For a single archtecture, a trnslator may support many
processor subtypes,e.g. ARM7, ARM9 etc.

As does the "program caller" gcc.  Since it needs to parse the
command-line and reject inappropriate options, it too is
architecture-specific to a certain extent.

The gcc setup is in the specifications file. Have a look
at

    gcc -dumpspecs

Ah, very interesting.  So one _could_ use the same "gcc"
executable with multiple toolchains by using the -specs=<file>
option.  Still, the default specs are built-in so the gcc
executable is configured for one target architecture, even
though that can be overridden at run-time.