[llvm] r201921 - Use relative rpath so that the installation and build dirs are relocatable.

[Alexander Potapenko]

This CL has also broken the ASan tests on OS X.
On OSX ASan runtime library is built as a shared lib and every
executable built with -fsanitize=address is linked with that library.
Previously it was enough for the user to build the compiler and the
test suite in order to execute the tests by running `make check-asan`.
But now the ASan runtime has its LC_ID_DYLIB set to
@rpath/libclang_rt.asan_osx_dynamic.dylib, so unless the runtime
library is installed into the system the binaries that depend on it
can't be executed:

$ ./t
dyld: Library not loaded: @rpath/libclang_rt.asan_osx_dynamic.dylib
  Referenced from: /Users/glider/src/asan/llvm/llvm_cmake_build/./t
  Reason: image not found
Trace/BPT trap: 5

There are two common use cases for ASan on OSX:
1) Clang or ASan developers build Clang and run the tests with ASan on
the same machine without installing the compiler
2) other developers build their code with ASan and either run the
binaries on the same machine or copy them to another one;

For 1) everything used to Just Work™, but is broken now. I'm going to
make CMAKE_INSTALL_NAME_DIR in projects/compiler-rt/lib/sanitizer
point to the libraries' absolute paths to fix that, if you do not
object.
For 2) we don't want to force our users to install the runtime into
the system, because it's still under development. Instead the users
are supposed to ship their binaries with the appropriate version of
the runtime lib, and they anyway have to fix the runtime library using
install_name_tool, so nothing changes for them with your change.

On Sat, Feb 22, 2014 at 5:54 PM, Tobias Grosser <tobias at grosser.es> wrote:
> On 02/22/2014 02:47 PM, Rafael Espíndola wrote:
>>>>
>>>> Does it work when building with configure?
>>>
>>>
>>>
>>> No, with configure it seems no rpath is set and I need to explicitly set
>>> LD_LIBRARY_PATH. The cmake behaviour now matches the autoconf behaviour.
>>> I
>>> earlier cmake behaviour was more convenient, but if there are reasons to
>>> go
>>> with the autoconf behaviour we can probably do this.
>>> In case this is necessary, I can change the buildcommands and ask Galina
>>> to
>>> restart the buildbots on Monday.
>>
>>
>> I guess you can say the change was intentional then. In general it
>> seems a bad (but admittedly convenient at times) to bake information
>> about the build setup in the binaries. What I have done is change the
>> logic just in polly to record where out of build-dir libraries are
>> found.
>>
>> It is up to you if you want to keep that in polly or you want to
>> switch to using LD_LIBRARY_PATH.
>
>
> Thanks for looking into this so quickly. The buildbots are green again.
>
> You are probably right, not hard-coding the library path is the cleaner
> approach. On the other side, I am tempted by the convenience the -rpath
> provides especially when working with different versions of polly and
> libisl. As I did not hear any packager complaining about the -rpath, I am
> tempted to leave it as it is with the comfort of having a patch in the git
> history that can change this if needed at some point.
>
> Cheers,
> Tobias
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits



-- 
Alexander Potapenko
Software Engineer
Google Moscow