[llvm-dev] Bootstrapping with in-tree libcxx

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Thu Dec 29 14:20:56 PST 2016


> On Dec 29, 2016, at 2:06 PM, Asiri Rathnayake via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
> 
> On Tue, Dec 27, 2016 at 2:45 PM, Carsten Mattner <carstenmattner at gmail.com <mailto:carstenmattner at gmail.com>> wrote:
> On Tue, Dec 27, 2016 at 3:38 PM, Asiri Rathnayake
> <asiri.rathnayake at gmail.com <mailto:asiri.rathnayake at gmail.com>> wrote:
> >
> >
> > On Tue, Dec 27, 2016 at 1:29 PM, Carsten Mattner via llvm-dev
> > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >>
> >> When I tried to build with -DLLVM_ENABLE_LIBCXX, I found out that
> >> it doesn't try to use the in-tree libcxx but looks for one built
> >> and installed in the system.
> >
> >
> > IIRC, -DLLVM_ENABLE_LIBCXX reduces to passing --stdlib=libc++ (see
> > [1]) to the compiler.
> >
> > What you can do is a two-stage build. On the first stage, build just
> > libc++ (ninja cxx cxxabi). On the second stage, re-configure with
> > -DLLVM_ENABLE_LIBCXX and build the rest of the tools. We have a
> > downstream builder that works this way to avoid a libstdc++ defect
> > on the host platform. I can't remember the exact details, can dig
> > them up if it helps.
> 
> Yes please, that would be helpful as an interim workaround.
> 
> Hmm, I have mis-remembered. We do have a two-stage build, but probably not what you want; stage-1 builds clang + libcxx using the host compiler (no -DLLVM_USE_LIBCXX is passed). Then the stage-2 build uses the compiler built on stage-1, along with the extra -DLLVM_USE_LIBCXX option.
> 
> I'll dig around a bit further, I thought this worked out of the box tbh.

A bootstrap 2-stage build is the usual way to get there. I’m not sure I really get the motivation of what we’re trying to achieve here that is really useful in a 1-stage build?

— 
Mehdi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161229/2e7c54b4/attachment.html>


More information about the llvm-dev mailing list