# Forum: ARM programming with GCC/GNU tools Basic crosscompiler terminology ?

 Author: July Jim (julyjim) Posted on: 2017-12-12 17:32

Rate this post
 0 ▲ useful ▼ not useful
This may be way too basic , but I am getting confused with SOME parts of
cross-compiling.

My objective is to "compile" on x86 (host) and run on (target) ARM.
Instead of "plain" compiler I will use cross compiler capable of
compiling ARM code on my host.

Gcc cross complier.
Cross compliers are "build  for specific architecture.

How do I verify that I downloaded the right "tool chain" from Eclipse
repository? ARM comes with Mx options.

As far as terminology goes - I did try some kind of "auto-tool" - it did
not work and  the "host" and "target" systems were " reversed" .

 Author: db8fs (Guest) Posted on: 2017-12-14 16:49

Rate this post
 0 ▲ useful ▼ not useful
July J. wrote:
> This may be way too basic , but I am getting confused with SOME
> parts of
> cross-compiling.
>
> My objective is to "compile" on x86 (host) and run on (target) ARM.
> Instead of "plain" compiler I will use cross compiler capable of
> compiling ARM code on my host.
>
> Gcc cross complier.
> Cross compliers are "build  for specific architecture.

Suppose having host (x86) and your given target architecture (arm). The
cross-compiler is NOT an arm-executable. But the cross-toolchain will
ensure:
- compiling/linking against the cross-target's sysroot, which is some
kind of local copy of the target's filesystem "/"
- assembling ARM asm files
- producing ARM ELF binaries (in most cases)

> How do I verify that I downloaded the right "tool chain" from Eclipse
> repository? ARM comes with Mx options.

Build your target project and use the 'file' command on the output file.

 \$ file ~/my/funny/arm_binary 

The output will indicate if your cross-compiler really build binaries
for the target.

Note that you then still have to validate the precise linking against
the correct sysroot (for using the right glibc/STL and stuff)

> As far as terminology goes - I did try some kind of "auto-tool" - it did
> not work and  the "host" and "target" systems were " reversed" .

You need to setup your shell environment correctly for making autotools
work. For OpenEmbedded/Yocto somewhere some nice environment_* file
should be laying around.

 Author: July Jim (julyjim) Posted on: 2017-12-14 18:42

Rate this post
 0 ▲ useful ▼ not useful
Thanks for reply.
I may be mixing things up too much , but I am finding  it hard to
identify some sort of flow in my application building.

I believe my biggest problem is to I get from "Build Project"  to
actually see the execution on the target.

I am rEally not that keen on writing commands on terminal which
apparently is everybody way to explain "how it works".

I am using IDE - Eclipse to build "hello word" program.
I can option my compilers with verbose option and RUN "Build Project"
I am guessing "Build Project" runs "make", but since that part was
always working I have not have a need to analyse "make" process.

I get compiler output and most of the time it does compile.
I have no idea how "make" fits into this process.

Basically flying blindfolded as far as "make" goes.

Than my next step is to "Run as" "Run configuration" and select to run
"TCF"

TCF is the "glue" to communicate to the target ( Agent via SSH) and the
result is "Terminal" output , on Eclipse IDE , which is the actual
"Hello word" as output on the target terminal.
I have another way to verify that the application is actually running on
the ARM system, I verify all USB ports on the ARM and send data to one
of them as plain serial port and flash DTR pin.

AS you can see I really do not know how it all fits together - BUT IT
WORKS.

I am attaching a compiler file output just to clarify some of my writing

I am currently trying to include external files to my app  so the
compiler complains, WORK IN PROGRESS!

P

: Edited by User

• $formula (LaTeX syntax)$