Consider adding `Backward-cpp` for `gz_build_tests`

[arjo129]

Desired behavior

Backward-cpp is used by gz-tools already and makes the debugging experience in gazebo a lot smoother. However, when we build unit tests for gazebo-sim downstream, we do not end up linking it with our unit tests. Thus when we have segfaults on the build farm we often don't have stack traces that may allow us to reproduce or reason about the error.

Alternatives considered

N/A

Implementation suggestion

The simplest way would be to link it in the gz_build_tests macro. Currently we have two versions of the library one in gz-launch and one in gz-tools perhaps we could find a way of exporting the target from gz-tools? TBH I have no idea what the right way would be.

[azeey]

This is a great idea. I had started working on generating core dumps using gdb on our CI (https://github.com/gazebo-tooling/release-tools/pull/1030), but @j-rivero was pointed out that that could be a security risk and instead suggested using gdb to print out the stack trace. I haven't had a chance to look at that in a while, but I'm definitely in favor anything that would help diagnose segfaults on our CI.

[arjo129]

I think right now I am prototyping on a branch. There are several issues I'll need to figure out:

• libbackward-cpp is available in the ubuntu repos but that does not seem to provide cmake targets
• We vendor backward-cpp in 2 places in our code base: (1) is in the gz-tools repo and another in gz-launch. It would make sense to consolidate it. I haven't figured the best way to package it yet. Perhaps re-exporting it fromgz-tools but that would force all libraries downstream to depend on gz-tools. Alternatvely we could provide the targets as part of gz_cmake.

[arjo129]

After some consideration. Rather than deal with the mess of vendoring accross different platforms, since this only affects our tests, and generally flakiness is usually observed in a few libraries, I'm proposing we "vendor" the library with our test suite (via static linking).