Jeremy Rifkin

The erroneous output is from using g++-10, -std=c++11, and ubuntu-22.04

Hi, thanks so much for the reply. I have my implementation at https://github.com/jeremy-rifkin/cpptrace/blob/4dac00a87f749752ca4a042c55806e71550da2e0/src/full/full_trace_with_libbacktrace.cpp and the test program at https://github.com/jeremy-rifkin/cpptrace/blob/4dac00a87f749752ca4a042c55806e71550da2e0/test/test.cpp It might be possible to reproduce with the following: ``` git...

I have constructed a better reproducible example that reproduces locally for me: repro_lib.cpp ```cpp #include #include #include #include #include #include #include struct stacktrace_frame { uintptr_t address; int line; int col;...

It looks like I'm running into the same issues when I have an executable -> a.so -> b.so (which then invokes libbacktrace).

Hi @nickdademo, what version of msvc do you have and what vcpkg commit are you on?

Hi @nickdademo, thanks! I think this is a msvc bug, which I'd encountered earlier and reported here https://developercommunity.visualstudio.com/t/MSVC-1938331290-preview-fails-to-comp/10505565. It looks like it will be fixed in the next release. I...

Hi @nickdademo, I've added a workaround upstream and libassert builds on msvc 19.38 should work as of b672ba234858a819a735eb4c18a708aed12e446c

Thank you for the report, I'll look into this. You shouldn't have to set the assert_DIR. Did you install with the `x64-windows-static` triplet?

Thanks for the additional info. I’m somewhat skeptical of things breaking due to it being named `assert`, it hasn’t caused problems in any of my testing. The reason for naming...

Apologies for the delay here. I'm getting back to libassert stuff now and I'll resolve this in the upcoming release.