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

[Alexey Samsonov]

On Mon, Feb 24, 2014 at 7:09 PM, Alexander Potapenko <glider at google.com>wrote:

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

Maybe, you can instead call
set(CMAKE_BUILD_WITH_INSTALL_RPATH OFF)
in top-level compiler-rt/CMakeLists.txt (if we don't want to build any
compiler-rt dynamic runtimes with rpath)?



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



-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140224/12d1ace4/attachment.html>