Toolchain Directory Structure

Hello,

I want to know a little bit more about toolchains and cross-compiling in
general. I examined the directory structure of the FriendlyARM toolchain
and made some conclusions on my own. So if somebody reads this, it would be
nice if you correct me, if I understood something wrong and give answers to
some questions I still have. The goal is to build my own Toolchain someday,
maybe ^^. Here we go step by step:

At first there is the root directory of the toolchain:
"/opt/FriendlyARM/toolchain/4.4.3/"
The directories here ( like bin, include , lib , ... ) contain everything
that runs on or has to to with the host-pc (in my case ubuntu-x64). In
"bin" there are some scripts and symlinks that are calling the actual gcc,
binutils or other binaries. This bin directory is on my PATH to cross
compile applications.

Then we go deeper into the "arm-none-linux-gnueabi" directory. The
bin-directory contains the actual gcc and binutils binaries that are
running on the host.
The debug-root and sys-root directories contain all binaries and libs that
run on the target, as well as target-specific include files and so on. When
developing an application for the mini2440, these includes are used and to
these libs my application gets linked to.
Then there is the include-directory, that only contains the C++-includes.
Here are my questions:
1. Why they are not located in sys-root/usr/include/c++ ? For example on my
host ubuntu machine, the C++-includes go under /usr/include/c++
2. The C++ include-directory contains another directory
"arm-none-linux-gnueabi". Is this to distinct between
architecture-dependent and -independent C++ includes ?

Oh, I meant to distinguish of course ;)

Some of these paths are set when the package gets configured via the
"./configure --this --and --that". Some others are default or built-in
settings of the toolchain. I think there is no fixed rule how to setup it.
Or some distros change it in their own way, because they do not like the
defaults...
On the other hand, you have not to care about these paths, as your
toolchain use them "automagically".