This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
Ranjit Mathew kirjoitti:
If I understand you correctly, you're saying that the
target runtime libraries are already created by the
cross-compiler in Phase 1, so I don't need to rebuild
them again in Phase 2 along with the crossed-native
compiler - I can get by by just building the compiler.
Yes, once being made and being thoroughly tested, any library shouldn't
be rebuilt. Doing that again only means a test for the compiler producing
the library - the result should by all sanity be identical in size and bytes
with the existing...
Definitely the cross-GCC for the $target on the $build host is the expected
compiler to produce the target libraries, not the new GCC being built for
the new $host and for the $target. In your case it could be possible to have
Wine installed and then trying to run the new MinGW-hosted native GCC
on the $build host, but this isn't the assumption, the $build-X-$target GCC
is the one producing the $target libraries, in your case the
'i686-mingw32-gcc'
(and all the stuff it uses as subprocesses, headers and libraries) or
something.
I don't know much about the internals of GCC, but what
you're saying should be possible though a bit cumbersome.
Building everything in Phase 2 (compiler and libraries)
just gives a nice bundle that I can then redeploy as I
wish (but this is precisely the thing that seems to be
broken, on MinGW at least).
I would go as far as not even producing that special "native GCC", but to
build instead a "MinGW-targeted and MinGW-hosted GCC" ! I have never
understood why the Windoze-host should cause the MinGW-targeted GCC
being in any way different from a Linux-hosted and MinGW-targeted GCC
in its install scheme... The MinGW-targeted GCC on Windoze really doesn't
need to mimic any proprietary "native 'cc'" which has its headers in
'/usr/include'
and its libraries in '/usr/lib' or something.... Maybe some Unix
sources could
require the X11 stuff being in its "native" places, but never that the C
headers
and libraries would be in some virtual "native" places....
After one has 50 or so MinGW-hosted GCCs for all kind of targets, that
very weird "native GCC" has this far sounded being an oddball among all the
other GCCs using the "cross GCC" scheme... But this opinion of mine seems
to be opposite to the current trend: If one has 50 or so GCCs, each one of
them should use its own "native" install scheme on the cross-host, the new
"--with-sysroot" tries to enable this new bright idea....
Anyway if even standardizing the $prefix for all the GCCs made by oneself,
for instance using the SVR4-like standard '/opt/gcc' as the $prefix,
one could
have quite identicallly installed GCCs on any host... Or the $prefix
could be
$host dependent, on Windoze/MinGW host for instance that '/mingw' being
the chosen $prefix for all the MinGW-hosted GCCs.... So when one has
only cross-GCCs everywhere and has only one standard $prefix in use
everywhere, copying becomes very easy. If one needs to copy the target
libs from '/opt/gcc/lib/gcc/i686-mingw32/3.4.6' on Linux onto just the same
place on Windoze, how this copying could be in any way cumbersome?
Ok, if the GCC configure command has for instance :
--build=i686-linux-gnu --host=i586-mingw32 --target=i686-mingw32
then the resulted GCC is a crosscompiler from 'i586-mingw32' to
'i686-mingw32'
because the $host is different from the $target.... And if the used
$prefix is the
same as used in the $build ('i686-linux-gnu' here) host, only the GCC
binaries
(the '.exe's for Windoze) would be different between the two MinGW-targeted
GCCs on Linux and Windoze hosts...
Generally it could be very informative to be capable to rebuild those
libraries on
more than one $build system using different $build-X-MinGW GCCs (but their
versions and the sources used to produce them being identical) and see
that the
results are really identical with identical GCC options being used in
compile. So
I really aren't against all "reinventions", only thinking that using
just the same GCC
once again for the same task isn't that "informative". But if you
really use the new
MinGW-hosted GCC for the rebuild on Linux using Wine, that could give some
new information about the quality of the new compiler...