[Interest] Qt 5 LTO build on OS X 10.9 (and earlier)

Thiago Macieira thiago.macieira at intel.com
Fri Sep 11 19:36:07 CEST 2015


On Friday 11 September 2015 18:33:05 René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > On Friday 11 September 2015 10:24:32 René J.V. Bertin wrote:
> > 
> > I've only ever tested LTO builds on Linux. That's where llvm-ar comes from
> > -- the *official* clang + LLVM build.
> 
> Quick check: my llvm 3.5.1 build on Linux indeed has llvm-ar, but it's got a
> -3.5 suffix like all other user-visible commands. I think that's what's
> official on Debian/Ubuntu at least; does Qt's build system pick up binaries
> named that way?

No, just like Qt won't pick up gcc-4.8, clang-3.5 or gcc-ar-4.9. You must 
provide a PATH entry that contains the binaries without suffix or you'll have to 
tinker with the mkspec (QMAKE_AR).

> >> It seems that the ar command works too though it complains about and
> >> ignores invalid debug info (which fits in with though doesn't fully
> >> explain my experience that LTO builds lack debug information in shared
> >> libraries).> 
> > That depends on whether the .o files were fat or thin.
> 
> I don't know of a way to chose between those options with clang, but if I

You don't. Clang does not have -f[no-]fat-lto-objects. Clang will do whatever 
it wants.

If it produces "thin" objects (LLVM bitcode only), then you must use llvm-ar 
to create the .a so that the symbol table is updated with the symbols that 
would have been there if the .o were "fat".

> understand you correctly and the .o files were thin, wouldn't that also
> cause executables to lack debugging info? Because executables do seem to
> have everything for normal debugging.

Actually, that has nothing to do with debugging.

That's just linking.

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




More information about the Interest mailing list