<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 24, 2014 at 7:09 PM, Alexander Potapenko <span dir="ltr"><<a href="mailto:glider@google.com" target="_blank">glider@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This CL has also broken the ASan tests on OS X.<br>
On OSX ASan runtime library is built as a shared lib and every<br>
executable built with -fsanitize=address is linked with that library.<br>
Previously it was enough for the user to build the compiler and the<br>
test suite in order to execute the tests by running `make check-asan`.<br>
But now the ASan runtime has its LC_ID_DYLIB set to<br>
@rpath/libclang_rt.asan_osx_dynamic.dylib, so unless the runtime<br>
library is installed into the system the binaries that depend on it<br>
can't be executed:<br>
<br>
$ ./t<br>
dyld: Library not loaded: @rpath/libclang_rt.asan_osx_dynamic.dylib<br>
  Referenced from: /Users/glider/src/asan/llvm/llvm_cmake_build/./t<br>
  Reason: image not found<br>
Trace/BPT trap: 5<br>
<br>
There are two common use cases for ASan on OSX:<br>
1) Clang or ASan developers build Clang and run the tests with ASan on<br>
the same machine without installing the compiler<br>
2) other developers build their code with ASan and either run the<br>
binaries on the same machine or copy them to another one;<br>
<br>
For 1) everything used to Just Work™, but is broken now. I'm going to<br>
make CMAKE_INSTALL_NAME_DIR in projects/compiler-rt/lib/sanitizer<br>
point to the libraries' absolute paths to fix that, if you do not<br>
object.<br></blockquote><div><br></div><div>Maybe, you can instead call</div><div><span style="font-size:13px;font-family:arial,sans-serif">set(CMAKE_BUILD_WITH_INSTALL_</span><span style="font-size:13px;font-family:arial,sans-serif">RPATH OFF)</span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif">in top-level compiler-rt/CMakeLists.txt (if we don't want to build any compiler-rt dynamic runtimes with rpath)?</span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br>
</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
For 2) we don't want to force our users to install the runtime into<br>
the system, because it's still under development. Instead the users<br>
are supposed to ship their binaries with the appropriate version of<br>
the runtime lib, and they anyway have to fix the runtime library using<br>
install_name_tool, so nothing changes for them with your change.<br>
<div class=""><div class="h5"><br>
On Sat, Feb 22, 2014 at 5:54 PM, Tobias Grosser <<a href="mailto:tobias@grosser.es">tobias@grosser.es</a>> wrote:<br>
> On 02/22/2014 02:47 PM, Rafael Espíndola wrote:<br>
>>>><br>
>>>> Does it work when building with configure?<br>
>>><br>
>>><br>
>>><br>
>>> No, with configure it seems no rpath is set and I need to explicitly set<br>
>>> LD_LIBRARY_PATH. The cmake behaviour now matches the autoconf behaviour.<br>
>>> I<br>
>>> earlier cmake behaviour was more convenient, but if there are reasons to<br>
>>> go<br>
>>> with the autoconf behaviour we can probably do this.<br>
>>> In case this is necessary, I can change the buildcommands and ask Galina<br>
>>> to<br>
>>> restart the buildbots on Monday.<br>
>><br>
>><br>
>> I guess you can say the change was intentional then. In general it<br>
>> seems a bad (but admittedly convenient at times) to bake information<br>
>> about the build setup in the binaries. What I have done is change the<br>
>> logic just in polly to record where out of build-dir libraries are<br>
>> found.<br>
>><br>
>> It is up to you if you want to keep that in polly or you want to<br>
>> switch to using LD_LIBRARY_PATH.<br>
><br>
><br>
> Thanks for looking into this so quickly. The buildbots are green again.<br>
><br>
> You are probably right, not hard-coding the library path is the cleaner<br>
> approach. On the other side, I am tempted by the convenience the -rpath<br>
> provides especially when working with different versions of polly and<br>
> libisl. As I did not hear any packager complaining about the -rpath, I am<br>
> tempted to leave it as it is with the comfort of having a patch in the git<br>
> history that can change this if needed at some point.<br>
><br>
> Cheers,<br>
> Tobias<br>
><br>
><br>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br>
<br>
<br>
</div></div><span class=""><font color="#888888">--<br>
Alexander Potapenko<br>
Software Engineer<br>
Google Moscow<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div>