Re: llvm/clang upstream

On 30 Nov 2021, at 14:27, Paul Floyd <paulf2718@gmail.com> wrote:
> 
> On 11/30/21 14:03, Michał Górny wrote:
>> 
>> Please note that the "official" way of building stuff has changed a few
>> times, so you might be using an outdated approach.  I think the current
>> way of building runtimes is via LLVM_ENABLE_RUNTIMES.
> I'll take a look at the 'official' llvm web pages tonight
> 
> Up to now I've been using
> 
> 
> cmake -G "Unix Makefiles" ../llvm -DCMAKE_INSTALL_PREFIX=~/tools/clang -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi;libunwind;compiler-rt;lldb;openmp;pstl"
> 
> 
> (just added libunwind)
> 
> 
> which gives
> 
> 
> /home/paulf/scratch/clang/llvm-project/compiler-rt/lib/sanitizer_common/sanitize
> r_unwind_linux_libcdep.cpp:26:10: fatal error: 'unwind.h' file not found
> #include <unwind.h>
>         ^~~~~~~~~~
> 1 error generated.

Yes, this is a rather annoying shortcoming of our base system, really.
We should provide unwind.h (and associated headers) directly in
/usr/include, while we have historically only provided it in our C++
include directories (/usr/include/c++/v1 now, but this used to be
/usr/include/c++/4.2.1 in the g++ times.)

The trouble is that we have dragged multiple slightly incompatible
unwind libraries and headers in our src tree for ages now, with no
really good solution in sight. At some point we should choose one of the
N implementations and stick that into /usr/include. :)

-Dimitry