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)
Issue 2785: check gold binutils version and don't use gc-sections for versions prior 2.25
due to https://sourceware.org/bugzilla/show_bug.cgi?id=17639
readelf --debug-dump=frames build/libosrm_extract.so
Contents of the .eh_frame section:
...
readelf: Warning: Invalid length 0xfff01dd8 in FDE at 0x000020
We build `osrm_contract` (the library) linking in libtbb. We then
build `osrm-contract` (the binary) linking in `osrm_contract` (the
library).
Because we're only using TBB's `parallel_invoke` in the code for the
binary, it seems like the linker discards some symbols in the library.
Therefore we have to link libtbb for the binary again. Even worse, the
order now matters: if we first link in `osrm_contract` and then libtbb,
we're still hitting the issue re. discarded symbols.
Therefore we first link in all dependencies (libtbb, libboost*), and
only then `osrm_contract`.
Strictly speaking, we probably have to do this for all of our binary
targets, or we will hit similar issues in the future.
- Throwing an assertion exception for proper stack unwinding, making
sure destructors are called
- On in Debug mode, in Release, enable via:
cmake -DCMAKE_BUILD_TYPE=Release -DENABLE_ASSERTIONS=ON
Current problem that I'm seeing is that some code is not catching
exceptions or worse silently swallowing them. Would like to check the
whole pipeline before merging this in.
Fixes issue #1864. Given the simple set-up:
a --> b --> c
^-----------|
This would translate into an edge based graph (ab) -> (bc),
(bc) -> (ca), (ca) -> (ab).
Starting at the end of the one-way street (ab) and going to
the beginning, the query has to find a self-loop within the
graph (ab) -> (bc) -> (ca) -> (ab), as both nodes map to the
same segment (ab).
This checks if `ccache` is available, and if so uses it.
The user can stil disable it via the ccache env variable, quoting:
disable (CCACHE_DISABLE) [boolean]
When true, ccache will just call the real compiler, bypassing the cache completely. The default is false.
At least Clang required `CCACHE_CPP2`.
The user does not have to set up anything, just to install ccache.
Of course, things like the cache's max size, its location and so on can
be configured.
References:
- https://ccache.samba.org/manual.html
By linking in the coordinate object file twice, we violate the ODR,
resulting in our program to not be "well-formed" in language lawyer
speak (hint: bad, very bad).
(How come no one noticed this all the time, this was introduced
somewhere between v4.5.0 and v4.6.0 from a quick look...)
References:
- C++14 standard (N3936.pfd): 3.2 One definition rule [basic.def.odr]
- http://eel.is/c++draft/basic.def.odr
We were stuck on the 4.5.0 tag from develop, since we searched for the
latest tag, but release tags are done on the master branch.
This commit rips out all the code for deriving the version on git tags.
Instead, we define major, minor, and patch versions in the CMakeLists
and then pass it on to:
- the `libosrm.pc` `pkg-config` file
- a `version.hpp` header that makes use of the preprocessor's string
concatenation to provide an easy way for generating version string
literals such as "v4.8.0".
That is, in the source code please now use the following defines:
#define OSRM_VERSION_MAJOR "@OSRM_VERSION_MAJOR@"
#define OSRM_VERSION_MINOR "@OSRM_VERSION_MINOR@"
#define OSRM_VERSION_PATCH "@OSRM_VERSION_PATCH@"
#define OSRM_VERSION "v" OSRM_VERSION_MAJOR "." OSRM_VERSION_MINOR "." OSRM_VERSION_PATCH
- remove profiling/coverage mix from debug build, as it is useless as of
now, re-enable this for a separate coverage build in the future
- use gcc's `-ggdb` and `-Og` flag (requires recent gcc) to provide
better debug information targeted for gdb and optimize what we can
- use `-fno-inline` and `-fno-omit-stack-pointer`, in order to be able
to jump around in gdb without functions being gone and keeping the
stack reference
This refines the last commit of parallelizing lto.
Discussion: this is ugly as hell, dispatching 1/ on the availability of
the `-flto` flag, then 2/ on the compiler since GCC allows `-flto=n`
whereas Clang for example does not.
I tried setting the CMake property `INTERPROCEDURAL_OPTIMIZATION`,
without any effect. All I could see was some lto related utilities in
the cmake debug output, but not in the actual compiler or linker
invocation.
This would eliminate the need for our hacks, with 1/ using an option
`WITH_LTO` setting `ON` by default, and based on this value setting the
`INTERPROCEDURAL_OPTIMIZATION` flag with CMake doing the actual work of
selecting the best LTO method on the target platform.
By the way, this also fixes a bug where we reset the `CMAKE_CXX_FLAGS`
to a variable that was never defined, resulting in setting the flags to
an empty string. Yay CMake, as usual.
References:
- http://www.cmake.org/cmake/help/v3.0/prop_tgt/INTERPROCEDURAL_OPTIMIZATION.html
GCC with link time optimizations does not to respect this mode
unfortunately, reuslting in warnings in release (default) build
mode from system includes such as boost, luabind and so on.
This remove the `-fPIC` flag, indicating position independant code
generation, from the build system.
Citing GCC's official code generation docs:
> This option makes a difference on the m68k, PowerPC and SPARC.
We do not support any of these architectures, so remove the flag!
References:
- https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options
These are for standard compliance and should on by default:
-Wall -Wextra -pedantic
The problem is that even `-Wall` and `-Wextra` does not cover all
warnings, as to not break backward compatibility. Clang therefore
has the `-Weverything` flag, that really includes everything but is
overkill for the day to day development.
Thus, we in addition add:
-Wuninitialized -Wunreachable-code
to guard against undefined behavior from reading uninitialized variables
and warn for unreachable code.
With:
-Wstrict-overflow=1
the compiler warns us when it's doing optimizations based on the fact
that signed integer overflows are undefined behavior.
With:
-D_FORTIFY_SOURCE=2
we tell the compiler to replace functions like strcpy with strncpy where
it can do so, resulting in cheap and useful buffer overflow protection.
References:
- https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
- https://securityblog.redhat.com/2014/03/26/fortify-and-you/
- https://wiki.debian.org/Hardening
Only specify the flags we change from the default.
doxygen -g Doxyfile
Generates a default Doxyfile.
Also, make the docs not depend on `dot`, but conditionally create graphs
if `dot` is available, and if not still generate docs.
