cross-toolchain and x86 target status
Hello.
Thank you everyone who provided my access to several non-x86 hosts.
The situation is the following.
gcc-3.3 builds ok for x86 target.
gcc-3.4 and gcc-4.0 fail, because they try to be multilib (x86/x86_64), and
debian-amd64 people use somewhat strange way to handle multi-target
development, e.g. amd64-libs-dev package diverts many files from libc6-dev
and linux-kernel-headers. Diversions can't be handled by dpkg-cross (and
probably won't be - maintainer scripts for native packages are not
appropriate for cross packages, and are discarded by dpkg-cross).
There have been some discussion in debian-devel some time ago about making
all debian miltiarch-friendly. If this work will be ever done, it will
hopely result in more consistent system than diversions of one arch's
development files by other arch's evelopment files. So I am going to
postpone futher work on x86 targets until that time. After all, since x86
is the platform used by most developers, cross-compiling for it is of less
interest.
Alternative way is to make x86 target working, but not multilib (without
x86_64). Or to take x86_64 as completely different architecture. But I
don't feel to like it.
Nikita
P.S.
Another interesting issue is tool naming. How should tools be named:
i386-linux-gcc or i586-linux-gcc? And when comes to multilib, should
'i386-linux-gcc -m64' be the way to build for x86_86, or there should be
separate x86_64-linux-gcc? And what about binutils? Btw, same issue exists
on s390/s390x and on sparc/sparc64.
Looks that a consistent way is to make any compiler capable to build for
every compatable target, but to build by default for the target that is in
it's name. E.g. i386-linux-gcc by default builds core for i386,
i686-linux-gcc builds code optimized for 686, and x86_64-linux-gcc by
default builds for x86_64. But all those are several frontends for single
compiler binary in gcc-lib/, so 'i386-linux-gcc -m64' could be actually the
same as 'x86_64-linux-gcc'.
But I've never seen things done this way, so it probably is not easy, and
it's not clear whether it is worth effort or not.
Reply to: