3

I'm using Gentoo Linux.

Here is my toolchain:

sys-kernel/linux-headers-3.9
sys-devel/binutils-2.23.1  USE="cxx nls zlib -multislot -multitarget -static-libs {-test} -vanilla"
sys-devel/gcc-4.7.3-r1:4.7  USE="cxx fortran gtk lto mudflap (multilib) nls nptl openmp (-altivec) -doc (-fixed-point) -gcj -go -graphite (-hardened) (-libssp) -multislot -nopie -nossp -objc -objc++ -objc-gc -regression-test -vanilla"
sys-libs/glibc-2.17:2.2  USE="(multilib) -debug -gd (-hardened) -nscd -profile (-selinux) -suid -systemtap -vanilla"

Here are my CFLAGS:

$ cat /etc/portage/make.conf

CFLAGS="-march=core-avx-i -mtune=core-avx-i -O2 -pipe -flto"
CXXFLAGS="${CFLAGS}"

CHOST="x86_64-pc-linux-gnu"
# etc...

The whole world is built with LTO, except for few packages:

$ cat /etc/portage/package.env

dev-lang/perl no-lto
dev-libs/elfutils no-lto
dev-lang/spidermonkey no-lto
dev-libs/glib no-lto
sys-devel/llvm no-lto
media-libs/mesa no-lto
media-libs/alsa-lib no-lto
sys-apps/preload no-lto
app-text/aspell no-lto
app-text/rarian no-lto
sys-power/upower no-lto
net-libs/farstream no-lto
dev-python/notify-python no-lto
x11-libs/wxGTK no-lto
media-video/avidemux no-lto
media-gfx/inkscape no-lto
x11-base/xorg-server no-lto
x11-drivers/xf86-video-intel no-lto
net-libs/webkit-gtk no-lto
mail-client/thunderbird no-lto

$ cat /etc/portage/env/no-lto

CFLAGS="${CFLAGS} -fno-lto"
CXXFLAGS="${CXXFLAGS} -fno-lto"
LDFLAGS="${LDFLAGS} -fno-lto"

On some blogs I noticed authors setting LDFLAGS in their make.conf file also, I didn't do that.

The operating system sets these LDFLAGS according to selected profile:

$ emerge --info | grep LDFLAGS

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

Gentoo developers and maintainers do not recommend changing them

I would like to set these lines in my make.conf file, then rebuild toolchain and world:

CFLAGS="-march=core-avx-i -mtune=core-avx-i -O2 -pipe -flto -Wl,-flto"
LDFLAGS="-Wl,-flto -Wl,-O2"

Will there be any difference in performance/stability?

Are these differences worth the time needed to recompile entire world?

I'd like to hear suggestions, explanations, better practices from experienced Gentoo users/maintainers/programmers/administrators...

Thank you very much in advance!

  • From your link they do not really disencourage you to change them. They just say it is not necessary. Also you did not change them. The output of emerge --info is what is already set, so setting it the same value explicitly does not change anything. This question might be more on topic on unix.stackexchange.com so don't be confused when it gets moved there (the accounts from both sites are merged if you register with the same authentification), – Tim Oct 10 '13 at 19:29
  • @Tim Do you meen --as-needed is automatically replaced by -Wl,-flto -Wl,-O2? – user2868193 Oct 11 '13 at 0:31
  • Sorry I missed that difference. You are changing something them. By the way: Shouldn't you enable LTO in the LDFLAGS as well? – Tim Oct 11 '13 at 6:31
  • By the way, -march is a superset of -mtune. Having both is pointless. – Daniel B Dec 14 '14 at 21:00
1

You don't need to change your CFLAGS there to add -Wl,-lfto; unless there are some packages that are mistakenly using CFLAGS for linking, it won't help (and those packages should be reported to bugzilla).

You do however need to add -flto to LDFLAGS to get full benefit of LTO. LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-flto"

You will not actually get LTO performance until you have the addition in your LDFLAGS, so yes, you will need to recompile anything that did not explicitly enable/disable LTO itself.

1

When doing LTO builds, it is important to pass the same optimization flags to both the compiler and the LTO linker. This does not mean just -On, but actually all other optimization flags.

When you build the final binary and link using the compiler itself in a single pass, it all works. If you do it in two passes (libtool, I am looking at you!) then all hell breaks loose.

So, yes, it is exactly right to enforce that everything optimization-related in CFLAGS and CXXFLAGS is also present in LDFLAGS. And they must match for the results to be correct, the fact that the gcc documentation seems to imply otherwise is a reported bug against gcc.

Whether you need to enforce it by doing nothing special to LDFLAGS, or duplicating them in LDFLAGS depends on the build system used by the package, and whether late-linking by libtool and its ilk will happen.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.