Diego 'Flameeyes' Pettenò wrote: >> * a large part of the justification is based upon a misunderstanding of >> how cross compilation should be done. The correct way around this >> problem was already posted to the thread by solar. > No I'm not misunderstand how cross compilation should be done with a package > manager. I'm saying that this will anyway give a hand to that. What I was > referring to mostly comes down to the fact that, if I want to build a bin > package for amd64 nocona arch, right now I am not guaranteed that setting > CFLAGS to -march=nocona will produce the right result.
Using a proper profile and not hardwire useflags to use amd64 is a solution too. > No it is not. Want to get the news? People at binutils were discussing about > adding -march support to gas, so that it would refuse to build asm sources > that contains instructions not supported by the -march value passed. That works this way already on ppc but... > So using -march=i586 with mmx useflag wouldn't work anymore. ...I don't see why not since gas is supposed to accepth -m* flags related (see man as) > > For what concerns me, I brought the idea, I find the single regression > acceptable, I find it a proper usage of $CFLAGS variable, I find the > internals guaranteed enough to work. My work is done here, I leave to anybody > else to say what they think, as it seems I'm not the only one thinking this > is a good idea. > Amen but isn't the only way and as I told you already I'd rather have stuff properly set in profiles specific even if I like the idea of being able to check for compiler support. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list