<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - clang doesnt use library search path that it was built with"
href="http://llvm.org/bugs/show_bug.cgi?id=20510">20510</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>clang doesnt use library search path that it was built with
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>C++
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>btorpey@nyx.com
</td>
</tr>
<tr>
<th>CC</th>
<td>dgregor@apple.com, llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=12845" name="attach_12845" title="config log">attachment 12845</a> <a href="attachment.cgi?id=12845&action=edit" title="config log">[details]</a></span>
config log
The symptom of this problem is that clang builds can fail with an error similar
to:
clang++: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found
(required by clang++)
This appears to be because clang does not "remember" the search path it was
built with. In this case, clang was built w/gcc 4.9.0, which is installed in
/usr/local.
/shared/clang $ /usr/local/bin/gcc -print-search-dirs
install: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/
programs:
=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.9.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/bin/
libraries:
=/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.9.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/lib/../lib64/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../x86_64-unknown-linux-gnu/4.9.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib64/:/lib/x86_64-unknown-linux-gnu/4.9.0/:/lib/../lib64/:/usr/lib/x86_64-unknown-linux-gnu/4.9.0/:/usr/lib/../lib64/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/lib/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../:/lib/:/usr/lib/
/shared/clang $ Release+Asserts/bin/clang++ -print-search-dirs
programs:
=/shared/clang/Release+Asserts/bin:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../x86_64-redhat-linux/bin
libraries:
=/shared/clang/Release+Asserts/bin/../lib/clang/3.6.0:/usr/lib/gcc/x86_64-redhat-linux/4.4.7:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64:/lib/../lib64:/usr/lib/../lib64:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../..:/shared/clang/Release+Asserts/bin/../lib:/lib:/usr/lib
As you can see, clang is picking up the library search paths from the system
default compiler (gcc 4.4), rather than the search paths with which clang was
built (gcc 4.9).
Using LD_LIBRARY_PATH is not an option -- our build scripts deliberately unset
LD_LIBRARY_PATH before linking to ensure that only specifically named library
paths are searched.
I'm attaching the config.log, which appears to show clang picking up gcc 4.9.0
for the build (as expected).
The command used to build clang is:
make clean distclean;CFLAGS="-std=gnu89" ../llvm/configure
--prefix=/build/share/clang --enable-optimized --enable-targets=x86_64 && make
At this point I'm not necessarily looking for a fix, but an indication whether
this is a legitimate problem with clang, or possibly a problem on our end.
Thanks!</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>