[cfe-dev] [RFC] Prefer libraries installed next to Clang over those from GCC

[David Chisnall via cfe-dev]

> On 31 Jan 2017, at 00:49, Hahnfeld, Jonas <Hahnfeld at itc.rwth-aachen.de> wrote:
> 
>> -----Original Message-----
>> From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David
>> Chisnall
>> Sent: Monday, January 30, 2017 6:04 PM
>> To: Hal Finkel
>> Cc: Hahnfeld, Jonas; cfe-dev at lists.llvm.org
>> Subject: Re: [cfe-dev] [RFC] Prefer libraries installed next to Clang over those
>> from GCC
>> 
>> On 30 Jan 2017, at 16:57, Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org>
>> wrote:
>>> I think this is an important usage scenario, but because of the complication
>> Chandler mentioned, I don't think we can enable it by default. I think it is
>> very reasonable to have some CMake flag that enables this behavior.
>> 
>> Unless we’re also passing -rpath or similar, then this may also lead to
>> confusion where you link against the /opt/clang/lib/libunwind.so, but end up
>> using /usr/lib/libunwind.so.  In this particular example, you’re relying on the
>> fact that the two libunwinds have different SO versions, but that’s by no
>> means guaranteed.
> 
> On the systems I work with, I can ensure that LD_LIBRARY_PATH is set correctly. This will result in the correct libraries to be linked.

Which is fine, if you’re (a) building everything with clang (no gcc-built shared libraries) and (b) able to [remember to] put that in your environment whenever you run a clang-built thing.

> 
>> 
>> Libunwind is a very bad motivation for this in general because:
>> 
>> - It’s an implementation of a standard ABI
>> - The LLVM and non-GNU versions (and the GNU fork of the non-GNU
>> version) are intended to be compatible
> 
> Should we then teach libcxx and libcxxabi to link against an already installed libunwind? Currently, there's only LIBCXXABI_USE_LLVM_UNWINDER which requires LLVM's libunwind to be built…

Doesn’t it do this automatically if you don’t specify to use the LLVM unwinder?  On FreeBSD, we use the unwinder from libgcc_s / libgcc_eh (which actually is the LLVM unwinder on head, but is called libgcc_* for compatibility) and libcxxrt as the C++ runtime library and all of this seems to just work.


>> - Linking both will cause things to go very badly wrong at run time
> 
> That's probably the point where I got it wrong last time: I had quite a lot of test failures...

Yes, and making it easier to get into this situation doesn’t sound like a good plan.  The unwinder and C++ ABI library are both low-level system components and just ripping them out and replacing them needs almost as much thought as replacing libc.  Making it a thing that end-users might to by mistake makes me very nervous.

David