# 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.
* Adds a data structure, RasterSource, to store parsed + queryable data
* Adds bindings for that and relevant data structures as well as source_function and segment_function
* Adds relevant unit tests and cucumber tests
* Bring-your-own-data feature
Problem:
- old solution was slow
- depending on the result of TarjanSCC, new distance tables and new phantom node vectors were created to run tsp on it
Solution:
- dont create new distance tables and phantom node vectors
- pass an additional vector with the information which locations are in the same component and ignore all others
fix bug for scc split computation
It is already included in the COORDINATES "OBJECT" target to which the OSRM
library is linked.
This fixes the possibility to build OSRM as a shared library.
