-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Nikita> P.S. Another interesting issue is tool naming. How should > Nikita> tools be named: i386-linux-gcc or i586-linux-gcc? And when > Nikita> comes to multilib, should 'i386-linux-gcc -m64' be the way to > Nikita> build for x86_86, or there should be separate > Nikita> x86_64-linux-gcc? And what about binutils? Btw, same issue > Nikita> exists on s390/s390x and on sparc/sparc64. Looks that a > Nikita> consistent way is to make any compiler capable to build for > Nikita> every compatable target, but to build by default for the > Nikita> target that is in it's name. E.g. i386-linux-gcc by default > Nikita> builds core for i386, i686-linux-gcc builds code optimized for > Nikita> 686, and x86_64-linux-gcc by default builds for x86_64. But > Nikita> all those are several frontends for single compiler binary in > Nikita> gcc-lib/, so 'i386-linux-gcc -m64' could be actually the same > Nikita> as 'x86_64-linux-gcc'. But I've never seen things done this > Nikita> way, so it probably is not easy, and it's not clear whether it > Nikita> is worth effort or not. > > > The same problem arises for ARM. gcc can target any of the ARM > processors, but fails to be multilib for them, especially wrt > big/little endian issues.
Are there any ARM big endian CPUs? I've never heared of such ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBm8oRv3x5OskTLdsRAodlAKCAD/wwCQ3tT5aQcpCo81mGfWCFAQCePvWc zfefsRGvqLH3UVz02seRrBY= =PTYa -----END PGP SIGNATURE-----
