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

Reply via email to