5.x, 6.x and CPUTYPE

Derek Kuliński takeda at takeda.tk
Mon Nov 7 10:11:48 PST 2005


Hello Joel,

Sunday, November 6, 2005, 10:21:56 PM, you wrote:

> Hi,

> I've noticed that some CPU definitions have changed in /etc/make.conf
> between 5 and 6. For good or for bad, I have up until now been building
> 5.x for both p3 and p4 architectures with 'i686' but this particular
> definition's removal from 6.x has given me cause to rethink my strategy.
> I'd like to know:

> Should I use 'i386' and build once for all, or use p3/p4 defs and build
> once for each? And if the latter, why? (does this give any worthwhile
> performance increase?)

i386 will guarantee you that it should work on any PC, while p3/p4
will tell compiler to try using instructions available in pentium 3 or
pentium 4.
I don't have any performance stats to prove that, but in theory the
code should be faster when you use p3 or p4 instead of i386.

> If I don't specify a CPUTYPE at all, will this be auto-detected in some
> way (which would probably not suit me) or will it fall back to i386?

I'm afraid it will fall back to value that will produce code that can
run on any PC (which is i386). Actually it won't provide any flag to
gcc, but gcc will assume i386.

> Is this a consistent requirement for world/kernel/ports?

> Finally, when building on a single host, but where multiple requirements
> are being met, is it possible to define different make.conf files for make
> or is it easier to just edit this file before each build?

As long as you defined the variable in this way e.g.:
CPUTYPE?=i686
(the question mark is not a typo)

This is actually recommended way to assign values like this one.

You can pass this argument in make command e.g.
make buildworld CPUTYPE=i686
make buildworld CPUTYPE=p4
etc.

If you don't give argument, then whatever you have in /etc/make.conf
will be assumed as a default value.

-- 
Best regards,
 Derek                            mailto:takeda at takeda.tk
CCNA, SCSA, SCNA, LPIC, MCP certified
http://www.takeda.tk

Profanity is the language all programmers know best. 



More information about the freebsd-stable mailing list