Re: [lmi] LLVM libc++

[Vadim Zeitlin]

On Tue, 12 Jul 2022 01:34:36 +0200 I wrote:

Me> On Mon, 11 Jul 2022 23:01:57 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:
Me> 
Me> GC> On 7/11/22 22:02, Vadim Zeitlin wrote:
Me> GC> > On Mon, 11 Jul 2022 19:03:25 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
Me> GC> > 
Me> GC> > GC> On 7/11/22 16:22, Greg Chicares wrote:
Me> GC> [...]
Me> GC> > GC> Should I hope for better clang diagnostics if I use its
Me> GC> > GC>   https://libcxx.llvm.org/
Me> GC> > GC> standard library?
Me> GC> > 
Me> GC> >  Yes, I think this might be the case and, in particular, I'd be 
curious if
Me> GC> > this particular error message is improved when using libc++. But 
mostly I
Me> GC> > always use libc++ because it's even more different from libstdc++ than
Me> GC> > clang itself is different from gcc and I've found several unportable
Me> GC> > constructs in my own code that correctly failed to compile (or 
compiled
Me> GC> > with warnings indicating a serious problem) with libc++, while they
Me> GC> > compiled just fine with libstdc++. Again, I'm sure the reverse must be
Me> GC> > possible as well, but as my primary compiler is gcc, I never 
encounter it.
Me> GC> 
Me> GC> Do you happen already to know exactly how to do that? I tried:
Me> GC> 
Me> GC>   /root[0]#apt-get install libc++-dev
Me> GC>   The following additional packages will be installed:
Me> GC>     libc++-13-dev libc++1-13 libc++abi1-13 libunwind-13 libunwind-13-dev
Me> GC>   The following packages will be REMOVED:
Me> GC>     libunwind-dev
Me> GC> 
Me> GC> and said "No" because I'm afraid it might break gcc unwinding.
Me> 
Me>  There is indeed a problem, since quite some time, in testing/unstable,
Me> with libc++ and libunwind-dev being incompatible with each other.
[...]
Me>  I keep hoping that sooner or later this problem will get resolved

 Hello,

 I think there is not going to be any other resolution and the old (HP)
libunwind-dev will just be removed and replaced with the newer (LLVM)
libunwind-NN-dev, which seems to supersede it, but not in a perfectly
backwards-compatible way.

 To be more precise, there are at least 2 incompatibilities, resulting in 2
problems when building lmi with the LLVM libunwind:

1. The libunwind.h header is now in /usr/include/libunwind instead of being
   directly in /usr/include. But, and this looks like a bug to me, this
   header still include <__libunwind_config.h> which is in the same
   directory, so you can't include it as <libunwind/libunwind.h>, but have
   to add /usr/include/libunwind to the include directories list.

2. UNW_LOCAL_ONLY is not used any more, so predefining it results in

---------------------------------- >8 --------------------------------------
unwind.cpp:211:34: error: macro "UNW_LOCAL_ONLY" is not used 
[-Werror=unused-macros]
  211 | #       pragma GCC diagnostic pop
      |                                  ^
cc1plus: all warnings being treated as errors
---------------------------------- >8 --------------------------------------

   I can't find any mention of local-vs-remote unwinding in LLVM version of
   the library, so it looks like this symbol just is not needed any longer.


 Both of these can be fixed in a number of ways, but I am not sure which
one would you prefer. For now I've done the following:

---------------------------------- >8 --------------------------------------
diff --git a/unwind.cpp b/unwind.cpp
index 20e85bf51..05d40d2f1 100644
--- a/unwind.cpp
+++ b/unwind.cpp
@@ -27,7 +27,12 @@ bool g_unwind = true;

 #if defined LMI_X86_64 && defined LMI_POSIX && defined __GLIBCXX__

-#define UNW_LOCAL_ONLY
+// This symbol must be defined when including older libunwind header that uses
+// it, but defining it with the newer one in libunwind subdirectory results in
+// a warning about unused macro, so avoid doing it.
+#if !__has_include(<libunwind/libunwind.h>)
+#   define UNW_LOCAL_ONLY
+#endif

 #include <cstdio>                       // fprintf()
 #include <cstdlib>                      // free()
diff --git a/workhorse.make b/workhorse.make
index cd300c317..55afe8cb8 100644
--- a/workhorse.make
+++ b/workhorse.make
@@ -342,6 +342,7 @@ lmi_include_directories := \
 sys_include_directories := \
   $(compiler_include_directory) \
   $(wx_include_paths) \
+  /usr/include/libunwind \
   /opt/lmi/third_party/include \
   $(localincludedir) \
   $(localincludedir)/libxml2 \
---------------------------------- >8 --------------------------------------

which looks like the minimal possible fix, should I make a proper commit
with this patch or would you prefer to do something else and, if so, what?

 Thanks in advance,
VZ

pgp5TKnL3BFdF.pgp
Description: PGP signature