Quick follow up for https://github.com/Project-OSRM/osrm-backend/pull/3570:
there is no reason not to build the `osrm-components` tool by defualt.
Backwards compatible. Users still specifying the option will see:
> Manually-specified variables were not used by the project:
> BUILD_COMPONENTS
This disables the `-flto` LTO flag by default since we're seeing
segfaults in compiler lto plugins, binutils and linker errors again and
again for various clang / gcc / binutils combinations.
Pass `-DNEBALE_LTO` to `cmake` in order to re-enable LTO.
LTO situation in short:
- LTO does not work at all for gcc<4.9
- With gcc>=4.9 the "slim" LTO format is getting used dumping IR
- Older binutils need LTO plugins which know how to read this IR
- Recent binutils handle this format all by themselves
- LLVM is more or less the same with some Clang versions segfaulting
If you need the performance benefit of LTO, make sure your compiler and
binutils are up to date and see for yourself if LTO builds work for you.
References:
- https://gcc.gnu.org/wiki/LinkTimeOptimizationFAQ
- https://github.com/Project-OSRM/osrm-backend/pull/3481#issuecomment-270618997
- https://github.com/Project-OSRM/osrm-backend/issues/3501
- https://github.com/Project-OSRM/osrm-backend/issues/3441
(and a ton of other LTO tickets if you search for them)
# The first commit's message is:
Add support for building against mason-provided deps
# This is the 2nd commit message:
back to just one travis job: linux/release
# This is the 3rd commit message:
remove pkg-config debugging [skip ci]
# This is the 4th commit message:
use clang++ 3.8.1 for mason builds since 3.8 is what we have been using
- Builds up ENGINE_LIBRARY_LISTING correctly to pass to pkg-config
- Previous behavior had major flaw and would result in paths in libosrm.pc like: "-L-L"
when the data was "-L/path -lfoo" or just "-lpthread" with no -L/path. It only worked correctly for static libraries
- Refactors to call find_package for boost in one place (helps prepare for upcoming mason PR)
