Compiler LTO binutils detection for gcc >= 4.9 seems to be broken on some platforms

[daniel-j-h]

These lines in CMakeLists.txt make sure we use gcc's binutils like gcc-ar for LTO on gcc >= 4.9.

The Ubuntu packages for gcc >= 4.9 name their binaries with a version suffix, such as gcc-ar-5

With gcc 5.2 on Travis, we see the code path for gcc specific binutils triggers but then trying to invoke gcc-ar fails since there is no binary named like that (i.e. the version suffix is missing).

Fix naming scheme to gcc-ar-4.9 in CMakeLists.txt.

Blocks:

• C++14. Let's do this. #1975 and
• [not ready] Switch to C++14 standard node-osrm#153

[springmeyer]

See also #2120, which is the new blocker for Project-OSRM/node-osrm#153 since I'd prefer to use clang++ over g++ because:

• We dodge the problem of not easily being able to upgrade from g++ 5.2 -> 5.3 on sudo:false machines
• Clang++ is much faster to compile OSRM

[springmeyer]

Blocks:
#1975 and
Project-OSRM/node-osrm#153

Both of those issues are solved and #2120 is also now solved which means:

• We support c++14
• We support -flto with clang++ 3.8.x + binutils 2.27

@daniel-j-h anything more to do around gcc before closing this? /cc @TheMarex

[daniel-j-h]

Some platforms are still hitting this issue (see #3441) which makes compilation fail by default.
Even on master (the soon-to-be 5.5 stable release).

[daniel-j-h]

Closing as resolved. We disable lto now by default: #3524.

If you know what you're doing you can pass -DNEBALE_LTO to cmake in order to re-enable LTO.