Ranjit Mathew wrote :
It seems that toolchain relocation, especially for
crossed-native builds, seems to be broken in mainline
while it used to work for earlier releases. The situation
seems particularly bad for Windows (MinGW).
In this issue was something I didn't understand.... Let's assume one
does this
thing as assumed :
1. builds a Linux or something (build system) hosted GCC for MinGW
target. During
this step one produces all the extra target libraries: libiberty,
libstdc++, libgcj,...
whatever will be produced during the GCC build for the MinGW target
after getting
the "GCC" binaries and the "GCC helper library", 'libgcc'.... The
new cross-GCC
for the MinGW target produces these libraries.
2. tries to produce another MinGW-target toolchain for some other host,
for which
one also has a cross-toolchain. The MinGW host maybe sounds being
somehow
special when the target too would be MinGW, but should that really
be? In any
case all the MinGW target libs would be produced again with the step
1 cross-GCC...
Because all the MinGW target libs already were produced during the step
1, it should
sound being "reinventing the wheel" to try to reproduce these during the
step 2....
So one uses the 'make all-gcc', and gets only the "GCC" binaries for the
new host.
That there would be any problems in reproducing the extra libraries will
remain totally
unnoticed...
Maybe there really is a difference between a 'native' build for these
extra libraries and
a 'cross' build for them... Maybe there is a buggy "$host = $target"
compare and then
a "native" build is assumed.... But why the builder should even try
this rebuild?
I have quite the same situation: All my MinGW-hosted stuff has been made
on Linux
for years. BUT I haven't ever tried to rebuild the stuff coming to the
'$build/$target'
after getting the '$build/gcc' stuff ready.... Why you think the
rebuild being somehow
necessary and you cannot just copy these extra libraries from your
$target-targeted
cross-compiler?
The MinGW-target wouldn't be any exception here, if I should produce a MinGW
hosted cross-GCC for Linux/PPC on Linux/x86, surely I wouldn't try to
reproduce
the 'libiberty', 'libstdc++-v3', 'libgcj' etc. for the Linux/PPC if I
already have them...
That others think that "reinventing the wheel" is something one must
always do, is
the weirdest thing for me, not that new bugs would appear.... I really
cannot say
whether there could be any motives to try to fix this, before doing that
it should be
some reason why using the 'make all-gcc' isn't enough in a "crossed
native" or in a
"crossed cross" build....
