Re: [arm-gnu] Include path problem in CC-ing busybox

[Rupesh Sugathan <rupesh_sugathan@xxxxxxxxx>]

> So as a generic question If I want to CC a utility like this using a 
> arm-none-eabi, then I would require all the underlying libs that a utility would 
> require using a arm-none-eabi isnt it ?
> 
> Like in this case, I've have to have a glibC ?
> Please explain...
> 

This is my understanding on this topic..Please correct or add if someone else knows it differently.

1) The naming of these 'pre-built" cross tool chains may not always be very explicit. below is what I think the naming means
2) You can almost be sure that the first field (here "arm") represent the "cpu" of your target. 
3) the next field (here "none") may represnt the either "kernel" or the
"operating system". none in your case means the tool assumes that the
compiled code do not run on a linux kernel. This field could be either
"linux", "elf" or "coff" etc depending on the target kernel.
4) if there a next field , it indicates the "operating system" of the
target. Note that the previous term indicated only the "kernel". I have
seen this field to be named "glibc", "uClibc" etc...In your case, this
field indicates that the operating system on the target is an "eabi",
meaning there are some capabilities to crate "alternate" machine
instructions for normally
unsupported machine instructions. My understanding is that ARM
compilers uses eabi tools a lot since many arm processors do not have
an FPU.
5) the last term ("gcc", "ld', "ar") of course refers to what tool it is

If you are going to run your built code on an arm/linux target, I suggest you to look for (or build yourselves) either
arm-linux-* or if you need it to be eabi, arm-linux-eabi-*

--
Rupesh