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

[David Chisnall via cfe-dev]

On 30 Jan 2017, at 16:57, Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> On 01/30/2017 09:09 AM, Hahnfeld, Jonas via cfe-dev wrote:
>> Hi,
>> 
>> 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 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.

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
- Linking both will cause things to go very badly wrong at run time

Unless you can ensure that everything is compiled either purely with clang or purely with gcc, and that you never compile something with one that uses libraries compiled by the other, then this is going to cause far more problems than it solves.

David