[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