[LLVMbugs] [Bug 19438] New: llvm-config --ldflags/--cxxflags works poorly in bootstrap scenarios

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Apr 15 16:44:11 PDT 2014


http://llvm.org/bugs/show_bug.cgi?id=19438

            Bug ID: 19438
           Summary: llvm-config --ldflags/--cxxflags works poorly in
                    bootstrap scenarios
           Product: tools
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-config
          Assignee: unassignedbugs at nondot.org
          Reporter: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140415/82074dd3/attachment.html>


More information about the llvm-bugs mailing list