When doing native bootstraps things are nice and easy ... the target
spec definitions are also appropriate for the host.
===
I've been doing some canadian X-s (specifically darwin 9 => darwin 7).
So, ... when doing B == H != T the specs might need to be different
from B != H == T (or B=H=T)
In effect the specs for the linker are used to generate code for the
'target' on the 'host'.
the problem comes when the B-host needs different specs from the
native case.
So when doing B == H != T (first cross - to build a compiler capable
of making T code on B) we need specs that the B understands
(this all works quite easily using --with-sysroot= .. etc. - and needs
to use the right specs to allow generation on the B system)
[ a specific case is inserting a path spec to point to the sysroot -
which the B linker understands]
When doing B != H == T (second cross - to make the compiler for T
hosted on T) we need to generate native specs that T understands.
[in my example the path spec causes the T==H linker to fail]
===
Is it legitimate to wrap these circumstances with #ifndef
CROSS_DIRECTORY_STRUCTURE ... #endif in the target headers.
(or maybe there's a flag somewhere that indicates H == T ?)
I recognize that this is changing the target headers depending on the
host ..
.. but at the moment I can't see how else to do it; the specs say "do
'this' to generate correct code for the target"
.. but "this" might well be host-dependent.
It doesn't seem to belong in confg/mh-* or gcc/config/x-*
any insight much appreciated.
Iain
