Find a sustainable way of enabling STL assertions #8044
Description
There have been a few issues caught, and a few issues produced by our inability to call non-inline-defined STL functions. Some of them would obviously never work on a GPU, but things like assert(3) should definitely work.
In no particular order, one way or another we have had to deal with (at least) the following because of this issue
There are various workarounds to ensure this works for assert(3), which in libstdc++ calls an extern "C" helper function. The upstream library developers have exercised their right to change the name of this function and subsequently these workarounds fail when libstdc++, libc++, glibc, musl etc change how their internal impls work.
We've discussed the issue in the above tickets, but have not come to a satisfactory conclusion on the matter. As a pragmatic hack to prevent failures on new libc versions / new host compiler versions [I changed the default cmake option for enabling these assertions to OFF in #7236
This ticket is to track the more long term solution, because playing catchup every time an external dependency changes its private implementation is no fun, and new users should not be alienated by cryptic compilation failures when checking out the project and building the project for the first time on a rolling distribution.
The options for solving this more generally include, but are not limited to:
- shipping our own device STL. I believe CUDA does something similar, but it is a big job and will need finesse around ABI compatibility with the host code.
- Printing a nicer error message saying I'm sorry that doesn't work for device code thankyou.
- tracking common upstream STL and libc implementations and being reactive (current approach, but not really sustainable)