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

Hahnfeld, Jonas via cfe-dev cfe-dev at lists.llvm.org
Tue Jan 31 00:49:52 PST 2017


> -----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.

> 
> 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...

> - 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5868 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170131/d76f54ce/attachment.bin>


More information about the cfe-dev mailing list