Bug 356231

Summary: Build not respecting "ranlib" and "ar" binaries
Product: [Applications] kdevelop Reporter: Pedro Ferreira <arkangath>
Component: generalAssignee: kdevelop-bugs-null
Status: RESOLVED UPSTREAM    
Severity: minor CC: arichardson.kde
Priority: NOR    
Version First Reported In: git master   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Pedro Ferreira 2015-12-03 10:01:25 UTC
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
Comment 1 Alex Richardson 2016-03-22 14:33:22 UTC
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 .
Comment 2 Pedro Ferreira 2016-03-22 15:25:33 UTC
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.