Question

我刚从LLVM网页下载了clang 3.3（自制软件）到我的mac（OS X 10.8.4），但在使用std=c++11 stdlib=libc++时出现了这个编译错误：

In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:594:
In file included from /usr/include/c++/v1/memory:590:
In file included from /usr/include/c++/v1/typeinfo:61:
/usr/include/c++/v1/exception:146:5: error: an attribute list cannot appear here
    _LIBCPP_NORETURN friend void rethrow_exception(exception_ptr);
    ^~~~~~~~~~~~~~~~
/usr/include/c++/v1/__config:190:28: note: expanded from macro '_LIBCPP_NORETURN'
#  define _LIBCPP_NORETURN [[noreturn]]
                           ^~~~~~~~~~~~

似乎我还需要另一个libc ++（尽管据说它在MAC上完成了100％），但我找不到任何。任何帮助赞赏。仅供参考：

> clang++ -v
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-apple-darwin12.4.0
Thread model: posix

而且，是的，我用Google搜索并发现：http://comments.gmane.org/gmane.comp.compilers.llvm.bugs/24138声称它已在libc ++ trunk中解决了???

好的，正如Howard所建议的那样，我已经将tip-of-the-trunk libc ++下载到/ opt / local / share / libcxx中，但是在构建它时遇到了麻烦。手册对cd libcxx/lib，export TRIPLE=-apple-说，然后运行./buildit。我认为这意味着bash（我通常是tcsh用户，因此我移动了.tcshrc，获得了一个新的shell并启动了bash）。我做到了，编译工作，但库构建失败。显然./buildit没有看到$TRIPLE=-apple-，因为它选择了错误的LDSHARED_FLAG（不是第81行，而是第103行，如果是$TRIPLE则会使用未设置），即使echo $TRIPLE会产生-apple-。当我在echo TRIPLE = $TRIPLE的顶部添加语句buildit时，它不会报告任何内容。怎么会？这有什么不对？

失败的原因是因为错误的LDSHARED_FLAG被选中了加载不起作用（ld抱怨未知选项-soname，我认为这在linux下是有意义的。我不知道为什么buildit（#! /bin/sh文件）没有获取TRIPLE环境变量（它确实选择了几个不需要的文件变量，例如CXX和{ {1}}）。我现在只是在该文件的顶部添加CC，它确实构建了库。然而，装载机发出了几个警告，所有警告都是

形式

ld：警告：在___cxa_bad_typeid中直接访问std :: bad_typeid的全局弱符号typeinfo意味着在运行时无法覆盖弱符号。这可能是由于使用不同的可见性设置编译了不同的翻译单元造成的。

但最重要的是，它的工作原理（至少编译，我还没有测试过这个库）。我有一个最后的问题。建议是使用TRIPLE=-apple-和-I告诉编译器这个版本的下落。是不是可以把它放到通常的地方-L？请注意，无论如何，Xcode在其他地方都有它的版本，并且我已经为这个版本添加了一个符号链接（/usr/include/c++/v1/）以使我的自制文件clang 3.2工作（在一些Xcode更新之后）。图书馆怎么样？我还能把它放在标准的地方吗？

Answer 1

这是libc ++的主页：

http://libcxx.llvm.org

您可以从那里下载tip-of-trunk libc ++。您可以通过-nostdinc++ -I<path-to-libc++>/include告诉clang指向您的下载。您还可以告诉clang使用-L<path-to-libc++>/lib和export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib链接到您的tip-of-trunk libc ++。方向都在libc ++主页上。

Xcode是获取clang + libc ++的最简单方法。但如果你想要最新的，那就是去的地方。

恭喜！

不要担心ld警告。这是一个无害的ld bug，将在未来版本中修复。我也在10.8.4上看到了它并没有伤害任何东西。

libc ++标头不再存在于/usr/include/c++/v1。 Xcode已将它们迁移到自身。从较旧的安装版本/usr/include/c++/v1获得libc ++标头一直是混乱和错误的根源。我经常使用-nostdinc++ -I指向我想要的libc ++标题（我经常会同时使用多个版本），这对我来说很有用。

您可以将/usr/lib/libc++.1.dylib替换为您已构建的/usr/lib。我不建议这样做。我有时要进行正确的测试，但我总是非常小心，因为有时这会导致我必须重新启动到备份磁盘并将/usr/lib/libc++.1.dylib恢复到原始状态。如果你选择这条路线，那么备份原始-L是非常好用的。

我建议在命令行中使用export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib，在shell中使用testit。不遵守这个建议，不止一个人（包括我自己）将他们的计算机变成了一个非常讨厌的地方。

如果您运行test/（在DYLD_LIBRARY_PATH下），那么您在shell中只需要testit。 buildit脚本设置为指向没有安装的正确位置。

我还建议找出你必须修改printenv的原因。没有人看到这种行为。命令行上的{{1}}可能对此有所帮助。

libc ++经常更新。我们试图保持行李箱始终处于可运输的状态。

LLVM libc ++不能在Mac OS上使用clang 3.3进行编译

1 个答案: