[Interest] building Qt 4.8.7 with gcc 5 and link-time optimisation on Linux

Thiago Macieira thiago.macieira at intel.com
Thu Jul 23 19:52:24 CEST 2015

On Thursday 23 July 2015 10:31:01 René J. V. Bertin wrote:
> And actually, I'm now fooling around with a project that just builds qtbase
> (5.4.2), and it seems that I need -r even immediately after calling
> configure.

configure should generate exactly one Makefile: the top-level.

> > That's also why Qt 4's configure had the -fast option. Which wasn't the
> > default. I don't know why anyone would intentionally choose a slow build
> > with no further benefits...
> ? If -fast just let configure skip the recursive qmake call, what difference
> did it really make? In the end you'd be doing all those qmake calls
> anyway...

Actually, there are three solutions:
1) use qmake to generate the Makefiles
2) generate a stub Makefile that calls qmake on first run
3) generate only the top-level Makefile

#1 was the default in Qt 2, 3, and 4. #2 was Qt 4's -fast option. Qt 5 
switched to #3.

And you're perceptive... in certain situations, -fast is slower than the 
regular slow build!

> But in that register: why is qmake itself not built in parallel? I've been
> patching the configure script to "fix" that, and it works fine.

export MAKEFLAGS=-jN

Boom! Now it is! Supported since 2001.

> > The compilation itself is faster because there's no code generation for
> > GCC
> > (due to -fno-fat-lto-objects). I don't remember whether Clang -flto
> > produces
> Hmm, I forced fat lto objects in the Qt 4.8.7 build on Linux, just to be
> sure (I don't want to end up with binaries that force me to use LTO for
> everything all the time).

Again a feature of ltcg.prf: it turns fat binaries back on for static 

For dynamic libraries, there are no ill effects.

> > LLVM and code or just LLVM bytecode. I know ICC doesn't, but for me it
> > takes 30 minutes to link QtCore and an infinite amount of time for QtGui
> > (it gets OOM-killed due to swap exhaustion before it finishes).
> With Qt 5 and ICC? 

Actually, ever since 4.7, which is when Intel first gave me a licence to use 
ICC 11. I've never been able to do an IPO build of QtGui -- I've never had 
enough RAM for it.

> > Unless you're me, you don't want to do this.
> Do I have any reason to be you? :)

Yes. That's when you disassemble the generated code to check if it is optimal. 
Reading the assembly in a .o is faster and easier than waiting for the full 

> > I only have evidence for other projects, where LTO did have noticeable
> > runtime performance effect.
> I certainly hope this is going to pay off on my slow(er) machines, as well
> as during periods of high CPU loads. Any reduction in GUI (and middleware)
> overhead is a gain, IMHO, esp. if it can be obtained with build options.

I watched Jon Kalb's session this week at the PDXCPP meeting and he mentioned 
large, modern datacentres report the largest costs are:

	* hardware
	* power distribution
	* cooling
	* power

So even if you make software only 1% faster, there's still a gain because you 
consumed 1% less power (actually, I think he said that gives you a 0.91% power 

> BTW: OS X's -mdynamic-no-pic option used to give me an approx. 15% gain,
> which I think is impressive for a single option that doesn't even increase
> compile time (and I was equally impressed with the Shark tool that pointed
> out to me that I should be using it). That was on a 32bit PPC machine; I
> haven't clocked its impact on Intel architecture.
> In 64bit mode it can be used systematically, even for shared libraries. Does
> Qt use it?

I've never heard of it. I'll investigate.

I've been tracking GCC 6's -fno-plt option, which also shows great promise.

> > better able to eliminate dead code. That's often the result of the
> > -fwhole-
> > program part of -flto.
> GCC's documentation (man page) isn't really clear on -fwhole-program and
> when it applies or should be used. Apparently I should understand that the
> linker plugin knows when to apply it?

-flto activates -fwhole-program when linking a binary. You shouldn't worry 
about it.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Interest mailing list