Re: [lmi] PATCH: Build fixes after unwind.cpp addition

[Greg Chicares]

On 2/26/21 10:25 PM, Vadim Zeitlin wrote:
> 
>  I've created https://github.com/let-me-illustrate/lmi/pull/172 with a
> couple of small build fixes that are required to build lmi in the CI
> environment, build it using autotools and/or build it using clang since
> unwind.cpp addition.

[...snip details...]

>  If possible, I'd really like to merge the first two and, preferably,
> three (and, ideally, of course, all 5), commits soon. Please let me know if
> you see any problems with doing this or any questions about the changes
> here.

Okay, I've done
  $git fetch xanadu
  $git cherry-pick ..xanadu/unwind-build-fixes
and will push after my next nychthemeral test.

I'll take it on faith that...

  commit 1aa86defc7e
    It is unnecessary to check for GNU compiler being used for the code only
    compiled when GNU Standard C++ library is, as is the case since the
    parent commit.

...although I thought it was possible to use libstdc++ with clang.

As for...

  commit 65d3ef327e4

     #include "unwind.hpp"

    -#if defined LMI_X86_64 && defined LMI_POSIX
    +#if defined LMI_X86_64 && defined LMI_POSIX && defined __GLIBCXX__

...I wondered whether __GLIBCXX__ is sure to be defined at this point.
It turns out that yes, it is (iff it should be), because "unwind.hpp"
includes "config.hpp". And that's the only reason for "unwind.hpp" to
exist--otherwise, it's...

  // Deliberately empty. This header is just lmi's canonical place to
  // include "config.hpp". The exception unwinder exposes nothing to any
  // other lmi code.

and the reason I created it was to make sure LMI_X86_64 and LMI_POSIX
are (conditionally) defined, so nothing further is needed to make sure
__GLIBCXX__ works the same way here.

Let me make some general comments about 'unwind.cpp'.

I added this for the proximate reason that lmi's map_lookup() throws:
    "map_lookup: key '" << key << "' not found."
That's just the most common cause of a general problem: exceptions
lack context, so it's hard to figure out how to redress them. Showing
a stack trace whenever an exception is thrown solves that problem.
It solves it only for pc-linux-gnu with g++, but that's enough for me
personally; and debugging msw builds that are run via 'wine' has never
worked for me despite days of effort. If any input file causes an
exception to be thrown with a x86_64-w64-mingw32 GUI build, we can
just rerun it with a pc-linux-gnu CLI build (e.g., on our server).

It would be nice to do something like that for msw builds run on
native msw, but I don't want to spend time on that myself. Perhaps
once we upgrade to x86_64-w64-mingw32, wx will offer something
similar for GUI binaries? (Or maybe I'm remembering a segfault
handler.)

For pc-linux-gnu unit tests that use LMI_TEST_THROW(), this unwinder
reports the stack trace for every exception--even intentional ones
arising from LMI_TEST_THROW(). It shouldn't be hard to block that in
the definition of LMI_TEST_THROW(); I just haven't felt strongly
motivated to do that yet, because it causes no harm.