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.
From
> [warn} oops
to
> [assert] /tmp/osrm-backend/src/extractor/extractor.cpp:79
> in: int osrm::extractor::Extractor::run(): false
> terminate called without an active exception
This is more of a hack but looks like the best we can do.
The reason for this is the following:
1/ we require strict mode for our v4 script
2/ v0.10 in strict mode marks 'let' as a reserved keyword,
aborting before execution any code in the script. Thus,
we can't assert e.g. on process.versions['node'] !== '4'.
Aligned blocks prevent bus errors in NEON/VFP instructions.
Block pointers are aligned to 4 bytes, that is guaranteed
by aligned mmaped-pointers, the 4 bytes size of the CANARY block and
aligned sizes of blocks.
Failing test
features/car/traffic_turn_penalties.feature:33
Tables were not identical:
from | to | route | speed | time
| a | h | ad,dhk,dhk | 63 km/h | 11.5s +-1 |
| i | g | fim,fg,fg | 59 km/h | 12s +-1 |
| (-) a | (-) e | (-) ad,de,de | (-) 57 km/h | (-) 12.5s +-1 |
| (+) a | (+) e | (+) ad,de,de | (+) 58 km/h | (+) 12.5s +-1 |
| c | g | cd,de,ef,fg,fg | 63 km/h | 23s +-1 |
| p | g | mp,fim,fg,fg | 61 km/h | 23.5s +-1 |
| a | l | ad,dhk,kl,kl | 60 km/h | 24s +-1 |
| l | e | kl,dhk,de,de | 59 km/h | 24.5s +-1 |
| g | n | fg,fim,mn,mn | 57 km/h | 25s +-1 |
