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. OK - some folks start with proper tool-chain - on my IDE I "downloaded" 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" .
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. > > OK - some folks start with proper tool-chain - on my IDE I "downloaded" > 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.
1 | $ 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.
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
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.