[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