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

[Michał Górny via cfe-dev]

[Note: I think my previous reply didn't went when mail program crashed,
sorry if you get it twice]

On Mon, 30 Jan 2017 15:09:46 +0000
"Hahnfeld, Jonas via cfe-dev" <cfe-dev at lists.llvm.org> wrote:

> Background: I'm on CentOS 7 which has GCC 4.8 installed in /usr/bin and I'm
> installing Clang to, let's say, /opt/clang. (I'm doing so with
> CLANG_DEFAULT_CXX_STDLIB=libc++, just if you wonder why the following
> matters to me...)
> With the current behavior, -lunwind passed to Clang will pull in the system
> default non-GNU /usr/lib/libunwind.so.8. IMO it should take LLVM's version
> in /opt/clang/lib/libunwind.so.1
> 
> That's why I would like to change the default order for searching libraries
> in Clang. Currently (and most probably due to historical reasons), the
> Driver adds paths next to GCC first.
> I propose to prefer paths next to the installed Clang. You can find the
> patch doing the change here: https://reviews.llvm.org/D26244
> 
> However, this has a potential impact as Chandler pointed out in above patch
> if Clang is installed to /opt/software together with other software.
> With my proposed change, Clang will link against
> /opt/software/lib/libunrelated.so when passed -lunrelated whereas before it
> had preferred /usr/lib/libunrelated.so (assuming that the library exists in
> both places).
> Is that considered an important scenario or can we expect our users to
> install Clang separately?
> 
> Any other feedback on that topic?

I think the best way forward is to create a separate runtime libraries
directory for clang (similarly to how gcc has one). For example,
the x86 targets could use:

  /usr/lib/clang/5.0.0/lib/linux/i386
  /usr/lib/clang/5.0.0/lib/linux/x86_64

i.e. the same directory as compiler-rt uses right now + arch
subdirectory matching suffixes used by compiler-rt libraries.

Those (dedicated) directories could safely be prepended to library
search path without risking accidentally pulling in unintended
libraries. You could install LLVM libunwind there without risking it
getting mixed with system libunwind.

We already use a similar solution for clang-suite. If you'd like to
take a look at our patches, they're at [1,2]. Sadly, they're ugly
and I didn't find time so far to clean them up and submit.

[1]:https://github.com/pathscale/clang-suite/blob/master/patches/psclang/0005-Driver-Always-add-L-paths-for-clang-runtime-director.patch
[2]:https://github.com/pathscale/clang-suite/blob/master/patches/psclang/0006-Driver-Add-rpaths-for-internal-libdirs.patch

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170130/3b6f5e68/attachment.sig>