[gentoo-amd64] Please suggest settings and flags in /etc/make.conf?

[gentoo-amd64] Please suggest settings and flags in /etc/make.conf?

[Mark Knecht]

I'm just installing Gentoo on my first new machine in years. Can
anyone suggest which of the CPU flags below might best be added to
make.conf? The machine will be a standard desktop running rt-sources
and stable Gentoo.

This processor is 2 physical cores with hyperthreading enabled in each core.

Currently make.conf has only the standard stuff other than me adding
the MAKEOPTS line:

# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
CFLAGS="-O2 -pipe"
CXXFLAGS="-O2 -pipe"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="x86_64-pc-linux-gnu"
# These are the USE flags that were used in addition to what is provided by the
# profile used for building.
USE="mmx sse sse2"
MAKEOPTS="-j5"


Thanks,
Mark


processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i5 CPU         661  @ 3.33GHz
stepping        : 2
cpu MHz         : 3325.050
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 2
apicid          : 5
initial apicid  : 5
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
xtopology nonstop_tsc pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
ssse3 cx16 xtpr pdcm sse4_1 sse4_2 aes lahf_lm ida tpr_shadow vnmi
flexpriority ept vpid
bogomips        : 6649.95
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

Re: [gentoo-amd64] Please suggest settings and flags in /etc/make.conf?

[Juan Fco. Giordana]

On 01/22/2010 12:44 AM, Mark Knecht wrote:
> I'm just installing Gentoo on my first new machine in years. Can
> anyone suggest which of the CPU flags below might best be added to
> make.conf? The machine will be a standard desktop running rt-sources
> and stable Gentoo.
>
> This processor is 2 physical cores with hyperthreading enabled in each core.
>
> Currently make.conf has only the standard stuff other than me adding
> the MAKEOPTS line:
>
> # These settings were set by the catalyst build script that automatically
> # built this stage.
> # Please consult /usr/share/portage/config/make.conf.example for a more
> # detailed example.
>
> ...

See http://en.gentoo-wiki.com/wiki/Safe_Cflags

Also, take a look to what they say about -march=native.

Regards

Re: [gentoo-amd64] Please suggest settings and flags in /etc/make.conf?

[Mark Knecht]

On Thu, Jan 21, 2010 at 3:49 PM, Juan Fco. Giordana
<juangiordana@gmail.com> wrote:
> On 01/22/2010 12:44 AM, Mark Knecht wrote:
>>
>> I'm just installing Gentoo on my first new machine in years. Can
>> anyone suggest which of the CPU flags below might best be added to
>> make.conf? The machine will be a standard desktop running rt-sources
>> and stable Gentoo.
>>
>> This processor is 2 physical cores with hyperthreading enabled in each
>> core.
>>
>> Currently make.conf has only the standard stuff other than me adding
>> the MAKEOPTS line:
>>
>> # These settings were set by the catalyst build script that automatically
>> # built this stage.
>> # Please consult /usr/share/portage/config/make.conf.example for a more
>> # detailed example.
>>
>> ...
>
> See http://en.gentoo-wiki.com/wiki/Safe_Cflags
>
> Also, take a look to what they say about -march=native.
>
> Regards
>

Hi all,
   OK, thanks to everyone for your responses. It's 5AM and I'm going
to try and answer as much as I can to get more info. Things are very
hosed up with this machine after whatever instructions I gave grub
didn't work. At the point where I'm supposed to get a grub splash
screen I get a blinking cursor, then it flashes for less than a second
some of the rootnoverify part from grub.conf so it's finding
something, and then I get a message about windows not starting because
<Windows root>\system32\hal.dll is missing.

   I have not yet this morning booted again from the install CD and
chrooted into the new 64-bit install. As I said, it's 5AM.

   OK, specific to this response there's nothing on the Safe_Cflags
page about this specific processor. (i5-661) I'll continue to study
that and take a very conservative path.

   Today all I want is to boot Gentoo with nothing but @system. I'm
happy to build that 10 times over with new CFLAGS if necessary before
going on to ANYTHING in @world. I don't NEED Gentoo just yet - I want
it but don't need it. What I need is to get grub working and be able
to boot into Windows first so I'm going to focus on that.

Thanks,
Mark

Re: [gentoo-amd64] Please suggest settings and flags in /etc/make.conf?

[Lie Ryan]

On 01/22/10 11:44, Mark Knecht wrote:
> I'm just installing Gentoo on my first new machine in years. Can
> anyone suggest which of the CPU flags below might best be added to
> make.conf? The machine will be a standard desktop running rt-sources
> and stable Gentoo.
> 
> This processor is 2 physical cores with hyperthreading enabled in each core.
> 
> Currently make.conf has only the standard stuff other than me adding
> the MAKEOPTS line:
> 
> # These settings were set by the catalyst build script that automatically
> # built this stage.
> # Please consult /usr/share/portage/config/make.conf.example for a more
> # detailed example.
>q CFLAGS="-O2 -pipe"
> CXXFLAGS="-O2 -pipe"

You might want to add "-march=" flag to CFLAGS and CXXFLAGS. See
http://en.gentoo-wiki.com/wiki/Safe_Cflags

> # WARNING: Changing your CHOST is not something that should be done lightly.
> # Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
> CHOST="x86_64-pc-linux-gnu"

As the warning said, there is nearly no good reason to change CHOST.

> # These are the USE flags that were used in addition to what is provided by the
> # profile used for building.
> USE="mmx sse sse2"

No one size fits all, only you can decide the best USE flags combination
for your use. You probably wouldn't know the USE flags to use until you
emerged some programs. Before emerging, look at the USE flags and decide
whether you will need the feature activated by the flag, and whether you
want to activate the USE flags globally (add here) or locally for the
specific package (in /etc/portage/package.use).

You may want to look at /usr/portage/profiles/use.desc

> MAKEOPTS="-j5"



You might want to add your SYNC and GENTOO_MIRRORS options. Use the
mirrorselect program to choose the server to use.

If you're going to use GUI with X, you might want to add VIDEO_CARDS and
INPUT_DEVICES variable. Add the graphic and input driver you're using there.

Most emerges takes a long time; you most likely want to make portage a
low priority process so they does not disturb your daily work. Use
PORTAGE_NICENESS and PORTAGE_IONICE_COMMAND variable.

The FEATURES variable can set some useful optional portage features.
Look at "man make.conf" for valid options. Some options can speed up
compiling, others may increase security. Some of the most useful FEATURES:
- ccache: you'll need to emerge dev-utils/ccache and tune the CCACHE_SIZE
- parallel-fetch: the name describes best
- test: runs "make check" for packages that have them and fail the
install when the test don't pass. Be aware that quite a lot of package
is shipped with failed tests. You may want to add "--keep-going" when
emerging a large number of packages.
- userfetch, usersandbox, usersync: these may add a little bit of security.

See "man make.conf" for more options

> 
> 
> Thanks,
> Mark
> 
> 
> processor       : 3
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 37
> model name      : Intel(R) Core(TM) i5 CPU         661  @ 3.33GHz
> stepping        : 2
> cpu MHz         : 3325.050
> cache size      : 4096 KB
> physical id     : 0
> siblings        : 4
> core id         : 2
> cpu cores       : 2
> apicid          : 5
> initial apicid  : 5
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
> xtopology nonstop_tsc pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
> ssse3 cx16 xtpr pdcm sse4_1 sse4_2 aes lahf_lm ida tpr_shadow vnmi
> flexpriority ept vpid
> bogomips        : 6649.95
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 36 bits physical, 48 bits virtual
> power management:
> 

Re: [gentoo-amd64] Please suggest settings and flags in /etc/make.conf?

[Mark Knecht]

On Thu, Jan 21, 2010 at 7:05 PM, Lie Ryan <lie.1296@gmail.com> wrote:
> On 01/22/10 11:44, Mark Knecht wrote:
>> I'm just installing Gentoo on my first new machine in years. Can
>> anyone suggest which of the CPU flags below might best be added to
>> make.conf? The machine will be a standard desktop running rt-sources
>> and stable Gentoo.
>>
>> This processor is 2 physical cores with hyperthreading enabled in each core.
>>
>> Currently make.conf has only the standard stuff other than me adding
>> the MAKEOPTS line:
>>
>> # These settings were set by the catalyst build script that automatically
>> # built this stage.
>> # Please consult /usr/share/portage/config/make.conf.example for a more
>> # detailed example.
>>q CFLAGS="-O2 -pipe"
>> CXXFLAGS="-O2 -pipe"
>
> You might want to add "-march=" flag to CFLAGS and CXXFLAGS. See
> http://en.gentoo-wiki.com/wiki/Safe_Cflags
>
>> # WARNING: Changing your CHOST is not something that should be done lightly.
>> # Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
>> CHOST="x86_64-pc-linux-gnu"
>
> As the warning said, there is nearly no good reason to change CHOST.
>
>> # These are the USE flags that were used in addition to what is provided by the
>> # profile used for building.
>> USE="mmx sse sse2"
>
> No one size fits all, only you can decide the best USE flags combination
> for your use. You probably wouldn't know the USE flags to use until you
> emerged some programs. Before emerging, look at the USE flags and decide
> whether you will need the feature activated by the flag, and whether you
> want to activate the USE flags globally (add here) or locally for the
> specific package (in /etc/portage/package.use).
>
> You may want to look at /usr/portage/profiles/use.desc
>
>> MAKEOPTS="-j5"
>
>
>
> You might want to add your SYNC and GENTOO_MIRRORS options. Use the
> mirrorselect program to choose the server to use.
>
> If you're going to use GUI with X, you might want to add VIDEO_CARDS and
> INPUT_DEVICES variable. Add the graphic and input driver you're using there.
>
> Most emerges takes a long time; you most likely want to make portage a
> low priority process so they does not disturb your daily work. Use
> PORTAGE_NICENESS and PORTAGE_IONICE_COMMAND variable.
>
> The FEATURES variable can set some useful optional portage features.
> Look at "man make.conf" for valid options. Some options can speed up
> compiling, others may increase security. Some of the most useful FEATURES:
> - ccache: you'll need to emerge dev-utils/ccache and tune the CCACHE_SIZE
> - parallel-fetch: the name describes best
> - test: runs "make check" for packages that have them and fail the
> install when the test don't pass. Be aware that quite a lot of package
> is shipped with failed tests. You may want to add "--keep-going" when
> emerging a large number of packages.
> - userfetch, usersandbox, usersync: these may add a little bit of security.
>
> See "man make.conf" for more options
>

Thanks Lie - I've run Gentoo for a long time and understand the
process, but I'm not a programmer and always feel that the CPU
oriented use flags are somewhat obscure.

Anyway, right now that's not my problem. This must be my 20th install
following the install guide but this time on this machine I am unable
to boot anything. Once again grub has bit me and it's acting like it's
blown away even windows, but I'm also not getting my grub.conf menu so
I don't know what's going on.

10 years and no one in the group has managed to make a fool proof
install. Necessary for us fools...

I'll try again tomorrow.

cheers,
Mark

Re: [gentoo-amd64] Please suggest settings and flags in /etc/make.conf?

[Lie Ryan]

On 01/22/10 15:01, Mark Knecht wrote:
> Anyway, right now that's not my problem. This must be my 20th install
> following the install guide but this time on this machine I am unable
> to boot anything. Once again grub has bit me and it's acting like it's
> blown away even windows, but I'm also not getting my grub.conf menu so
> I don't know what's going on.

There isn't many ways for booting to fail; it's either a faulty grub
installation (e.g. forgetting to rerun grub-install), faulty grub.conf,
or faulty kernel config. The easiest way to boot gentoo is to use
genkernel; if you can boot using the genkernel, it means grub is
properly installed.

[gentoo-amd64] Re: Please suggest settings and flags in /etc/make.conf?

[Duncan]

Lie Ryan posted on Fri, 22 Jan 2010 19:02:24 +1100 as excerpted:

> On 01/22/10 15:01, Mark Knecht wrote:
>> Anyway, right now that's not my problem. This must be my 20th install
>> following the install guide but this time on this machine I am unable
>> to boot anything. Once again grub has bit me and it's acting like it's
>> blown away even windows, but I'm also not getting my grub.conf menu so
>> I don't know what's going on.
> 
> There isn't many ways for booting to fail; it's either a faulty grub
> installation (e.g. forgetting to rerun grub-install), faulty grub.conf,
> or faulty kernel config. The easiest way to boot gentoo is to use
> genkernel; if you can boot using the genkernel, it means grub is
> properly installed.

I did a recent install to my (32-bit-only) netbook, using a chroot image 
created on my main 64-bit machine, following loosely the 32-bit chroot 
guide.

That ran into grub problems, because the thumb-drive I was using to boot 
and to transfer the image, is also the grub rescue boot for my main 
machine, using grub-static (because my main machine is no-multilib, but 
with the 32-bit chroot image).  I had installed normal self-compiled grub 
in the (main machine not directly booted) 32-bit image, and when I went 
to install that and do the grub-install on the 32-bit netbook, I ended up 
with, I believe, a mix of the stage-1 grub-static and stage-2 grub, which 
didn't work.  Either that or the self-compiled grub didn't like one of my 
CFLAGS or something, which is possible, but I think it was a mix of the 
two.

In that case, I simply decided that if grub-static was good enough for my 
64-bit main machine, and was booting the netbook fine from the USB stick 
(which has kernels and grub menu options for both the 32-bit and the 64-
bit machines), it was good enough for the 32-bit machine as well.  So 
back in the 32-bit chroot image on my main machine, I unmerged grub and 
merged grub-static instead.  After an rsync 32-bit image to thumb-drive 
and thumb-drive to netbook, and a grub-install of grub-static on the 
netbook, it worked.

So now I'm using grub-static everywhere.  If you're having an issue with 
grub, perhaps grub-static will work for you as well.  Since it's a pre-
compiled package, the binaries it contain are well tested on quite a few 
machines by now, so there's no wondering if it was somehow screwed up 
with strange cflags or something.  If it doesn't work and at least get 
you to a grub prompt, it's almost certainly because the grub-install step 
failed.

One of these days I'll try again with grub, but I expect when I do it'll 
be with grub2.  Until grub2, I think I'll leave well enough alone and 
stick with grub-static.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Please suggest settings and flags in /etc/make.conf?

[Peter Humphrey]

On Friday 22 January 2010 03:05:55 Lie Ryan wrote:
> On 01/22/10 11:44, Mark Knecht wrote:

> > # These are the USE flags that were used in addition to what is
> > provided by the # profile used for building.
> > USE="mmx sse sse2"
> 
> No one size fits all, only you can decide the best USE flags combination
> for your use. You probably wouldn't know the USE flags to use until you
> emerged some programs. Before emerging, look at the USE flags and decide
> whether you will need the feature activated by the flag, and whether you
> want to activate the USE flags globally (add here) or locally for the
> specific package (in /etc/portage/package.use).

> > flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> > syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
> > xtopology nonstop_tsc pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
> > ssse3 cx16 xtpr pdcm sse4_1 sse4_2 aes lahf_lm ida tpr_shadow vnmi
> > flexpriority ept vpid

What I did recently is to go through the list of CPU flags one by one and 
check which of them had corresponding USE flags; I set those in make.conf on 
the assumption that, if the processor had that feature, I might as well let 
it use it.

-- 
Rgds
Peter.

Re: [gentoo-amd64] Please suggest settings and flags in /etc/make.conf?

[Lie Ryan]

On 01/22/10 16:26, Peter Humphrey wrote:
> On Friday 22 January 2010 03:05:55 Lie Ryan wrote:
>> On 01/22/10 11:44, Mark Knecht wrote:
> 
>>> # These are the USE flags that were used in addition to what is
>>> provided by the # profile used for building.
>>> USE="mmx sse sse2"
>>
>> No one size fits all, only you can decide the best USE flags combination
>> for your use. You probably wouldn't know the USE flags to use until you
>> emerged some programs. Before emerging, look at the USE flags and decide
>> whether you will need the feature activated by the flag, and whether you
>> want to activate the USE flags globally (add here) or locally for the
>> specific package (in /etc/portage/package.use).
> 
>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
>>> syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
>>> xtopology nonstop_tsc pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
>>> ssse3 cx16 xtpr pdcm sse4_1 sse4_2 aes lahf_lm ida tpr_shadow vnmi
>>> flexpriority ept vpid
> 
> What I did recently is to go through the list of CPU flags one by one and 
> check which of them had corresponding USE flags; I set those in make.conf on 
> the assumption that, if the processor had that feature, I might as well let 
> it use it.
> 

I can tell you that's actually a lot of work. A certain technology may
be called differently in the CPU flags and in USE flags; and often even
after activating the USE flags, you may still need to find the feature
in kernel config. I always wished there is a website that listed the CPU
flags with the relevant kernel config and/or USE flags.

Re: [gentoo-amd64] Please suggest settings and flags in /etc/make.conf?

[Mark Knecht]

On Thu, Jan 21, 2010 at 11:52 PM, Lie Ryan <lie.1296@gmail.com> wrote:
> On 01/22/10 16:26, Peter Humphrey wrote:
>> On Friday 22 January 2010 03:05:55 Lie Ryan wrote:
>>> On 01/22/10 11:44, Mark Knecht wrote:
>>
>>>> # These are the USE flags that were used in addition to what is
>>>> provided by the # profile used for building.
>>>> USE="mmx sse sse2"
>>>
>>> No one size fits all, only you can decide the best USE flags combination
>>> for your use. You probably wouldn't know the USE flags to use until you
>>> emerged some programs. Before emerging, look at the USE flags and decide
>>> whether you will need the feature activated by the flag, and whether you
>>> want to activate the USE flags globally (add here) or locally for the
>>> specific package (in /etc/portage/package.use).
>>
>>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>>>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
>>>> syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
>>>> xtopology nonstop_tsc pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
>>>> ssse3 cx16 xtpr pdcm sse4_1 sse4_2 aes lahf_lm ida tpr_shadow vnmi
>>>> flexpriority ept vpid
>>
>> What I did recently is to go through the list of CPU flags one by one and
>> check which of them had corresponding USE flags; I set those in make.conf on
>> the assumption that, if the processor had that feature, I might as well let
>> it use it.
>>
>
> I can tell you that's actually a lot of work. A certain technology may
> be called differently in the CPU flags and in USE flags; and often even
> after activating the USE flags, you may still need to find the feature
> in kernel config. I always wished there is a website that listed the CPU
> flags with the relevant kernel config and/or USE flags.
>
>
Agreed. Not that I'm signing up for doing a lot of work but what's
involved in starting some sort of small working group to maybe put
some of that info together informally? Maybe we can come up with
something over the next few months working together that could be the
basis of such a page?

- Mark

[gentoo-amd64] Re: Please suggest settings and flags in /etc/make.conf?

[Duncan]

Lie Ryan posted on Fri, 22 Jan 2010 14:05:55 +1100 as excerpted:

> The FEATURES variable can set some useful optional portage features.
> Look at "man make.conf" for valid options. Some options can speed up
> compiling, others may increase security. Some of the most useful
> FEATURES:

> ccache: you'll need to emerge dev-utils/ccache and tune the
> CCACHE_SIZE

> parallel-fetch: the name describes best

> test: runs "make check" for packages that have them and fail the
> install when the test don't pass. Be aware that quite a lot of package
> is shipped with failed tests. You may want to add "--keep-going"
> when emerging a large number of packages.

Also be aware that a number of packages are known to take a **LONG** time 
to do their tests -- several times the length of the actual compile.  
mysql is I believe the most (in)famous of these, with tests taking 
something like an entire day.  Similarly, some packages have additional 
(uncommon) dependencies that are /only/ brought in for the tests -- 
effectively you're installing extra packages /just/ for the tests.

Finally and perhaps most importantly, for at least one package (udev), 
enabling test has security implications -- the tests require an insecure 
build that upstream warns NOT to install in production environments, the 
tests are designed for development use only.

Thus, FEATURES=test is definitely one feature that should be considered 
well before enabling.  Yes, it does make your installation more robust in 
general, but there are implications that should be considered as well, 
and particular applications for which you will probably want the feature 
disabled.  (This can be accomplished using an appropriate /etc/portage/
bashrc, setting FEATURES=-test conditional on the specific exception 
package.)

> userfetch, usersandbox, usersync: these may add a little bit of
> security.

> See "man make.conf" for more options

My favorite is FEATURES=buildpkg, or if you're space-constrained, 
FEATURES=buildsyspkg.  If either/both of these are enabled, also consider 
FEATURES=fixpackages, and set the PKGDIR variable as appropriate, also.

This has saved me many an unnecessary recompile over the years, when some 
update went wrong, and I was able to simply emerge --usepkgeonly the 
previous version.  As the binpkgs are simply tarballs with some 
additional metadata tacked on the end, they can be browsed/opened with 
your favorite archiver as well, thus enabling troubleshooting such as 
quick checks of what a particular config file looked like by default, or 
simply browsing a particular package's as-shipped filesystem.  They also 
come in handy when, for instance, gcc is borked so you can't use it to 
rebuild gcc (just emerge --usepkgonly the binpkg), or portage or python 
is borked so you can't emerge at all (just untar a working version over 
top the live filesystem -- but be sure you have backups of the config 
files it includes, first).

Meanwhile, it's also worth considering LDFLAGS.  Here's mine:

LDFLAGS="-Wl,-z,now,--as-needed,-O1,--hash-style=gnu,--sort-common"

The -Wl bit is the gcc prefix, telling it that the rest of the LDFLAGS 
are for the linker.

-z,now tells the linker to resolve all links at load, instead of "lazy 
resolution", waiting until functions are needed in some cases to resolve 
them.  This one's purely personal preference, and will at times slightly 
increase application start times, but if there's going to be a problem, 
I'd rather it happen when an app is starting, instead of crashing later, 
after I have unsaved work.  There are very rare circular library 
dependency issues with this as well. (A library loads functions from 
another library, which needs functions from the first.)  One example was 
xf86-video-ati, but that one has long had a check in the ebuild that 
disables the flag, if it's found.  I've not had issues running with this 
for some time, now.

--as-needed is the one most folks will be interested in.  There's talk of 
eventually making this the Gentoo default, as it can DRAMATICALLY reduce 
the number of reverse dependency breakage of the sort revdep-rebuild 
fixes.  I'm talking an order of magnitude reduction, having to rebuild 
maybe 1/10 of the packages that would have to be rebuilt without it.  
Problems with this one should now be quite rare indeed, because many 
people run with this LDFLAG, and Flameeyes (Diego P) actively tests 
packages for breakage with it on his tinderbox, filing bugs and helping 
devs patch where needed.  Given the major benefits in reduced revdep 
breakage and relatively low risk, I'd DEFINITELY recommend this one.  
(FWIW, if you want JUST this one: LDFLAGS="-Wl,--as-needed" .)

-O1 is linker optimization, similar to gcc's -O flags, only there's just 
the one level.  I /think/ this might be the gentoo default, but am not 
sure.

--hash-style=gnu tells the linker to use GNU style function-lookup 
hashing.  There's another style available also (IDR the name ATM), and 
"both" can also be used.  The Gentoo default, AFAIK is "both", altho 
there has been some discussion of switching that to "gnu", as there's 
little reason to include both unless you're compiling for use on other 
than Gentoo GNU/Linux (IOW, using prefix for the BSDs, or something).

--sort-common is another slight look-up optimization, tho in typical use, 
you'll not notice it.  This has been discussed as a Gentoo default and in 
fact, I think it is already, tho I'm not sure.

As mentioned above, --as-needed is the big one with real benefits and 
little down side due to already active usage.  The others, take or leave, 
as you wish.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Please suggest settings and flags in /etc/make.conf?

[Frank Peters]

On Fri, 22 Jan 2010 12:49:27 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> 
> Meanwhile, it's also worth considering LDFLAGS.  Here's mine:
> 
> LDFLAGS="-Wl,-z,now,--as-needed,-O1,--hash-style=gnu,--sort-common"
> 
> --as-needed is the one most folks will be interested in.  There's talk of 
> eventually making this the Gentoo default, as it can DRAMATICALLY reduce 
> the number of reverse dependency breakage of the sort revdep-rebuild 
> fixes.  I'm talking an order of magnitude reduction, having to rebuild 
> maybe 1/10 of the packages that would have to be rebuilt without it.  
> Problems with this one should now be quite rare indeed,
>

I've been using the "--as-needed" option for some time now and
probably most of my system has been rebuilt with it.

In my experience, the only package where "--as-needed" causes
problems is libdrm, which will not compile using this option.
The solution is to define a specific LDFLAGS variable without
"--as-needed" just for libdrm in the /etc/portage/env directory.

I forget what this method is called, but using the /etc/portage/env
directory is one way to allow CFLAGS, LDFLAGS, etc. to be
customized for individual packages.

Another example of this kind of customization is that both Python
and Sqlite supposedly perform better with "-O3" in the CFLAGS variable.
By making an appropriate entry into /etc/portage/env one can specify
"-O3" just for these packages but use "-O2" for all other packages.

Frank Peters

Re: [gentoo-amd64] Please suggest settings and flags in /etc/make.conf?

[Mark Knecht]

On Thu, Jan 21, 2010 at 7:05 PM, Lie Ryan <lie.1296@gmail.com> wrote:
<SNIP>
>
> You might want to add "-march=" flag to CFLAGS and CXXFLAGS. See
> http://en.gentoo-wiki.com/wiki/Safe_Cflags
>
<SNIP>
>
>>
>>
>> Thanks,
>> Mark
>>
>>
>> processor       : 3
>> vendor_id       : GenuineIntel
>> cpu family      : 6
>> model           : 37
>> model name      : Intel(R) Core(TM) i5 CPU         661  @ 3.33GHz
<SNIP>
>
>
>

The Safe CFlags page doesn't list the Core i5 yet, but it does have
the Core i7 which came out a bit earlier.

For all of the following keep in mind that I don't plan on putting any
desktops or applications on this machine for a couple of days so the
compile load will be smaller until I get this worked out. I need to
read up on this Intel VGA to see if I'm going to stick with it and if
so how to get X11 to work with it.

My question is if I choose the flags shown below for the i7 am I
likely to render the machine unusable in any way? I'm not against
recompiling with other flags if these turn out to be less than optimum
at some later date, but I don't want to cause big problems.

Or, as Juan suggested I might try -march=native. However if I go that
way then I'm not sure yet whether I am supposed to turn on the
additional msse4/mcx16/msahf flags or whether =native does that
itself? I'm not using distcc so I don't think that's a problem and I
like the idea of =native for someone like me, but on the other hand I
don't generally like auto-magic sorts of solutions.

Anyway, if none of these will likely render the machine unusable and I
can do another emerge -e @system to change then it's no big deal. I
just compiled emerge -e @system - 137 packages - in a little over an
hour so doing it a few times is no big deal.

Thanks,
Mark

64 bit profile (amd64) - for >=sys-devel/gcc-4.3

CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=core2 -msse4 -mcx16 -msahf -O2 -pipe"
CXXFLAGS="${CFLAGS}"