osrm-extract linking eats all memory

[nilsnolde]

first time I try to build osrm from source on arch linux, some experiences:

• tbb from package manager is incompatible, I ended up building & installing the ubuntu 20.04 version, worked fine
• real problem is that ld eats up all RAM while building osrm, no matter how few threads I run it with (and I have 32 GB). make just hangs on linking osrm-extract, then ld's memory usage keeps growing until the computer is bogged down.. I left it running for ~30 mins, memory is gone after 15 mins or so

EDIT: that also happens for Relase mode (and Debug of course as well)

did anyone experience that before? not sure if it'd make anything better, but I can't use the gold linker unfortunately, I get

/usr/bin/ld.gold: fatal error: out of file descriptors and couldn't close any

(it's not a ulimit problem, ulimit -Sn is 20000)

[nilsnolde]

forgot the versions of things:

ld: 2.38 gcc: 11.2.0

[SiarheiFedartsou]

As for tbb, should we simply vendor it and build from source?

[nilsnolde]

Are you rather referring to this one? https://github.com/Project-OSRM/osrm-backend/issues/6266

[SiarheiFedartsou]

tbb from package manager is incompatible

I mean all these issues that OSRM cannot be built with modern versions of TBB. What I am thinking about is that we may migrate to some modern version of it(https://github.com/oneapi-src/oneTBB) and instead of using something like FindTBB.cmake which finds TBB on the system we can just put the source code of TBB into the repo under third_party folder(like we do with flatbuffers). It would guarantee that we’ll never have problems like this in the future. The only cons I see is that it would slightly increase build time.

[danpat]

If anyone has the time, it might also be worth considering bumping our minimum C++ version to C++17 or C++20, then migrating our use of TBB to some of the STL parallel algorithms - our usage of TBB is not too extensive, in quite a few spots it's probably trivial to use something like std::for_each(std::execution::par, .... (I haven't used the execution policy stuff in the STL extensively, but it does seem to address many of the same issues that TBB was built for and why we used it back in 2015).

[nilsnolde]

my point was that has pretty much nothing to do with this issue which is that osrm can’t be built on arch linux since the linking doesn’t work. tbb issues are noise in this context.

#6266 is a better place IMO. if everything should be vendored or other tools than mason should be explored, I’m not feeling very opinionated about.

[stoecker]

instead of using something like FindTBB.cmake which finds TBB on the system we can just put the source code of TBB into the repo under third_party folder(like we do with flatbuffers). It would guarantee that we’ll never have problems like this in the future. The only cons I see is that it would slightly increase build time.

From a software packagers point of view I can only discourage such an approach. An important rule for package building is to always use system libraries. We even unbundle a lot of software again. The reason for this rule should also be obvious - it's impossible to fix security issues in bundled libraries (and it wastes space). BTW that also means that download deps on build approaches are incompatible with proper packaging.