Re: r219385 build error.

From: Alexander Best <arundel_at_freebsd.org>
Date: Mon, 7 Mar 2011 21:49:35 +0000
On Mon Mar  7 11, George Liaskos wrote:
> >What process did you follow to get here?
> 
> I did a make toolchain followed by make buildworld.
> 
> > that's because the latest gcc commits have support for core2 and thus it no
> > longer is being expanded to nocona. please note that having core2 in make.conf
> > has always been *wrong*. hence the need to reset it to nocona.
> > the best way to fix this would be to set CPUYTYPE?=native. if you want core2
> > support now's the chance to actually get it. just update world and you can use
> > CPUTYPE?=core2 and this time it *really* is supported. ;)
> 
> I saw the relevant commits about core2, this is the reason i decided
> to do a rebuild.
> I didn't know that core2 was wrong, it's in the make.conf
> documentation, "native" it's not and after serious googling i found
> out that i should actually avoid it.
> 
> I always believed that core2 was there [make.conf] as a future proof
> upgrade path for when the base toolchain actually supports core2.
> 
> So, should i use native cputype?

either "native" or "nocona" (actually native should evaluate to nocona):

touch _native_test.c && gcc -march=native -### _native_test.c

should tell which -march and -mtune settings gcc assumes for "native".

indeed there are some known problems with "native", but i think those are
limited to architectures such as mips and arm. with i386 or amd64 "native"
shouldn't cause any problems.

i think core2 was always wrong to set in make.conf, because the base gcc simply
does not support it. however so many people are trying to boost speed etc. by
adding make.conf options they find scattered over the internet and on various
linux dist wikis, that core2 was added as a workaround so people could use it
(even though it wasn't supported).

cheers.
alex

-- 
a13x
Received on Mon Mar 07 2011 - 20:49:35 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:12 UTC