[llvm-dev] (Thin)LTO llvm build
Carsten Mattner via llvm-dev
llvm-dev at lists.llvm.org
Thu Dec 22 02:45:39 PST 2016
On Wed, Dec 21, 2016 at 6:10 PM, Teresa Johnson <tejohnson at google.com> wrote:
> Or maybe it is picking up a different libstdc++ from somewhere else on your
> system?
> Here's the check from the cmake file:
>
> # There doesn't seem to be an easy way to check the library version. Instead,
> # we rely on the fact that std::set did not have the allocator constructor available
> # until version 4.9
> check_cxx_source_compiles("
> #include <set>
> std::set<int> s = std::set<int>(std::allocator<int>());
> int main() { return 0; }"
I cannot make g++ 6.2.1 fail to build the test snippet with
or without the archlinux-default/custom CXXFLAGS and LDFLAGS.
Time to find the real error and what's happening.
> LLDB_USING_LIBSTDCXX_4_9)
>
> So the version check isn't precise, but unless libstdc++ 6.2.1 doesn't have this
> interface available, which seems unlikely, something else is going wrong.
That seems risky to ignore then. I guess I'll postpone the rebuild until this
can be resolved/explained.
Also because ideally I want to do it that way, and it's a goal for a
future default
build config of llvm as discussed recently here, I'd prefer to build
and then use
the in-tree libc++. But it doesn't seem like -DLLVM_ENABLE_LIBCXX has that
effect. Shouldn't it or if not why can't it? I would certainly welcome
and find natural
that the in-tree libc++ is used when LLVM_ENABLE_LIBCXX=ON. The need for
a pre-built and installed libc++ is less practical.
More information about the llvm-dev
mailing list