我刚刚从LLVM网页下载了clang 3.3（homebrew）到我的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％完成），但我找不到任何libc ++。任何帮助表示赞赏。只为您的信息：
> 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 ++干线中已解决？
好的，正如霍华德（Howard）所建议的，我已经将笔尖的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和CC）。现在，我只是TRIPLE=-apple-在该文件的顶部添加了代码，它确实构建了该库。但是，装载机吐出了几条警告，这些警告的形式都是
ld：警告：___cxa_bad_typeid中的std :: bad_typeid直接访问全局弱符号typeinfo意味着弱符号不能在运行时被覆盖。这可能是由于使用不同的可见性设置编译了不同的翻译单元造成的。
但最重要的是，它可以正常工作（至少是编译，我尚未测试该库）。我还有最后一个问题。建议是使用-I并-L告知编译器此版本的下落。不可能把它放到平常的地方/usr/include/c++/v1/吗？请注意，无论如何，Xcode的版本都在其他地方，并且我已经在该符号上添加了一个符号链接（/usr/include/c++/v1/），以使我的自制clang 3.2正常工作（在某些Xcode更新之后）。那图书馆呢？我也可以将其放在标准位置吗？
这是libc ++的主页：
您可以从此处下载小技巧libc ++。您可以使用告诉clang指向您的下载-nostdinc++ -I<path-to-libc++>/include。你也可以告诉铛链接到你的尖的干线的libc ++-L<path-to-libc++>/lib和export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib。指示全部在libc ++主页上。
Xcode是获取clang + libc ++的最简单方法。但是，如果您想要最新的信息，那么这是一个去的地方。
恭喜你！
不用担心ld警告。这是一个无害的ld错误，将在以后的版本中修复。我也在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外壳中使用。不遵守此建议，一个以上的人（包括我自己）已经将他们的计算机放到了一个非常讨厌的地方。
如果运行testit（在之下test/），则只需DYLD_LIBRARY_PATH在该shell中即可。该testit脚本被设置为指向正确的位置，而无需安装。
我也建议弄清楚为什么必须修改buildit。没有人看到这种行为。printenv在您的命令行上可能会对此有所帮助。
libc ++经常更新。我们尝试将行李箱小费始终保持在可运送状态。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句