I'm not 100% certain this is an issue with KDevelop/KDevPlatform, but I don't know where else to look. I built everything git-head (including clang) with -flto under GCC 4.9.3. Just because - I'm just that silly. Clang builds and works fine. I then build KDevPlatform with the same configurations, but it failed to link with numerous linking errors. Those errors started after "ar" and "ranlib" failed to run because the objects being archived (or in the archive) do not have object code, only GIMPLE intermediate (due to -flto). The correct way of using LTO with those flags is to provide -plugin /path/to/libLTO.so OR use gcc-ar and gcc-ranlib. I opted for the second solution on clang, kdevplat and kdev CCMake configurations by adjusting CMAKE_AR and CMAKE_RANLIB. However, the build of KDevelop and KDevPlatform insist on using /usr/bin/ar and /usr/bin/ranlib instead of the CMake configured binary. On the plus side, if I make ar and ranlib shell scripts that call their corresponding "real" binaries with the -plugin option, KDev builds and works fine. Woo-hoo! Ultimately, whether Clang is built with flto is irrelevant. The issue is that the KDev components do not use the ar and ranlibs configured through CMake. I don't know where I should continue my investigation - I found no hard-coded "ranlib" binaries on either the source tree or the configured directory, which is why I suspect this problem comes from somewhere else. Reproducible: Always
I recall having a similar problem with CMake not wanting to use my custom ar binary in a different project. In the end I put an ar wrapper script into a new directory and prepended that to $PATH. Closing as this as an upstream CMake problem .
Not wanting to dispute your resolution, but I did mention that clang/llvm cmake system respected the toolchain decision, and I used the same cmake version.