<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:rnk@google.com" title="Reid Kleckner <rnk@google.com>"> <span class="fn">Reid Kleckner</span></a>
</span> changed
<a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - clang doesnt use library search path that it was built with"
href="http://llvm.org/bugs/show_bug.cgi?id=20510">bug 20510</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>RESOLVED
</td>
<td>REOPENED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>FIXED
</td>
<td>---
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - clang doesnt use library search path that it was built with"
href="http://llvm.org/bugs/show_bug.cgi?id=20510#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - clang doesnt use library search path that it was built with"
href="http://llvm.org/bugs/show_bug.cgi?id=20510">bug 20510</a>
from <span class="vcard"><a class="email" href="mailto:rnk@google.com" title="Reid Kleckner <rnk@google.com>"> <span class="fn">Reid Kleckner</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=20510#c3">comment #3</a>)
<span class="quote">> Reid:
>
> Dont get me wrong -- I’m nuts about clang in general, and especially the
> static analysis, sanitizers and related bits that help people, including us,
> build software that is more reliable and correct. And I’m very grateful to
> those, like you, who make that possible.</span >
Thanks!
<span class="quote">> With all due respect, however, what you suggest is a workaround, not a fix,
> and not a particularly good one either -- it requires manually adding the
> library search paths, not of the compiler, but of the compiler that the
> compiler was built with. Manually adding library search paths would be
> borked to begin with, but having to add the libraries that the compiler was
> built with is completely ridiculous.</span >
I don't think this is too bad, it's just one more linker flag on top of
installing and using a new version of GCC, which is already a tall order.
Setting an rpath is the standard way of using any library that is not installed
into /usr/lib. Clang is just a normal application that wants to use a newer
copy of libstdc++.
<span class="quote">> Please reopen this so that this bug (and it *is* a bug) is visible to
> someone who wants to work on fixes for the compiler.</span >
What action needs to be taken to make this easy? This really has more to do
with what gcc does when you compile a C++ app with it. It will add -L flags to
the link line, but it will not set an rpath.
<span class="quote">> In the meantime, I’m rebuilding clang with the native compiler (gcc 4.4.7)
> and hope that will work. I’ll post back here what I find out.</span >
(In reply to <a href="show_bug.cgi?id=20510#c4">comment #4</a>)
<span class="quote">> OK, clang wont build w/gcc 4.4.7 -- not surprising, as that's well
> documented.
>
> OTOH, that does make it more egregious that clang insists on using that
> compiler as its default search path.</span >
Clang is trying to act in exactly the same way as the "system" compiler, which
it assumes is installed in /usr, and will search /usr/include, /usr/lib, and a
variety of paths off of there. If you have a more modern gcc and libstdc++
toolchain that you want it to use, I believe you can set GCC_INSTALL_PREFIX at
configure time. I don't know how to do that in autoconf, though. My best
guess is --with-gcc-toolchain.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>