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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
