<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 --- - llvm-config --ldflags/--cxxflags works poorly in bootstrap scenarios"
href="http://llvm.org/bugs/show_bug.cgi?id=19438">19438</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>llvm-config --ldflags/--cxxflags works poorly in bootstrap scenarios
</td>
</tr>
<tr>
<th>Product</th>
<td>tools
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</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>llvm-config
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>fang@csl.cornell.edu
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>When bootstrapping llvm and clang against a built libc++ (alternating phases),
BuildVariables.inc gets polluted with paths pointing to builddirs, not suitable
for deployment.
Consider the following realistic bootstrap scenario:
* build llvm/clang stage 1, using host's c++ compiler/lib
* build libc++ using stage 1 (1.5)
* build llvm/clang stage 2, pointing to 1.5's build area for libc++
(CXXFLAGS,LDFLAGS)
* build libc++ using stage 2 (2.5)
* build llvm/clang stage 3, pointing to 2.5's built libc++
* install libc++ in custom location A
* install llvm/clang in custom location B (!= A)
* attempt to build something depending on llvm -dev headers, like dragonegg
Here's what goes wrong.
* llvm/clang stage 2 and 3 have no idea where libc++ will be installed, because
they are configured/cmake'd separately
* stage 3 takes CXXFLAGS,LDFLAGS pointing to built area of libc++ and
propagates to BuildVariables.inc
* BuildVariables.inc essentially exports its values to llvm-config(.cpp)
e.g.:
#define LLVM_LDFLAGS "
-L/sw/src/fink.build/llvm34-3.4-0e/llvm-3.4/../build/last-libcxx/lib -L/sw/lib"
#define LLVM_CXXFLAGS "-std=c++11 -stdlib=libc++ -cxx-isystem
/sw/src/fink.build/llvm34-3.4-0e/llvm-3.4/../libcxx-3.4/include -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default
-Wnon-virtual-dtor -O3 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS"
* llvm-config --ldflags/--cxxflags references no-longer existing build dirs
Ideally, --ldflags/--cxxflags should report where libc++ is actually installed.
This is kind of a packaging problem. I'm not sure adequate solution exists
until there's a way to distinguish between pre-install and post-install
locations of dependent libraries, like libc++ in this example.
Under fink packaging (bootstrapped), the built libc++ is installed in a
non-default location, so that built clang++ will search for system libc++ by
default, requiring -cxx-isystem to opt-in to the built libc++ (achieves
separation). The llvm-config issue was found when trying to build
dragonegg-3.4 using the built clang++.</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>