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

gcc already has a option "-mcu",may use arm or i386. But why I need arm-linux-gcc? what's different?

Reply to
uusky
Loading thread data ...

In fact you do need a tool chain. see:

formatting link

-Michael

Reply to
Michael Schnell

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.).

--
Grant
Reply to
Grant Edwards

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 > >

Reply to
uusky

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.

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

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

Reply to
Juergen Beisert

-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.

--
Grant Edwards                   grante             Yow! ... I want to perform
                                  at               cranial activities with
 Click to see the full signature
Reply to
Grant Edwards

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?

[d]m[i]] ]

v4t ]

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

form

h
Reply to
uusky

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.

--
Grant
Reply to
Grant Edwards

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.

Reply to
David Brown

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

gcc -dumpspecs

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

Ah, very interesting. So one _could_ use the same "gcc" executable with multiple toolchains by using the -specs= 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.

--
Grant Edwards                   grante             Yow! And then we could sit
                                  at               on the hoods of cars at
 Click to see the full signature
Reply to
Grant Edwards

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!

Reply to
uusky

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.