【问题标题】：Can't compile a C program on a Mac after upgrading to Catalina 10.15升级到 Catalina 10.15 后无法在 Mac 上编译 C 程序
【发布时间】：2020-02-05 06:18:54
【问题描述】：

之前有一个问题Can't compile C program on a Mac after upgrade to Mojave，该问题的答案已经涵盖了大部分问题的变化。

现在 — 从 2019 年 10 月 7 日星期一开始 — 您可以升级到 macOS Catalina 10.15。再一次，在升级过程中，/usr/include 目录已被更新所震撼，即使在升级（从 Mojave 10.14.6）到 Catalina 之前安装了 XCode 11.0。因此，预期存在/usr/include 目录的编译器不再工作。

Mojave 问题的主要推荐步骤 - 使用命令：

open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

由于目录/Library/Developer/CommandLineTools/Packages/ 不存在（因此还没有要打开的.pkg 文件），因此无法正常工作。

有没有好的（官方）方法来创建和填充目录/usr/include？

【问题讨论】：

您不需要/usr/include 就可以通过 Apple 当前的 Xcode 使用 Apple 的开发人员工具。标题等位于Xcode.app/Contents/Developer/Platforms/SomePlatform/SDKs/SomeSDK。（将头文件保存在不同的目录中是支持多个目标平台所必需的，最好不要有/usr/include，以确保在针对与主机系统不同的版本时不会意外使用其中的文件。）@987654331 是什么@show 显示活动开发者目录的路径？
我构建了 GCC 9.2.0（在 Mojave 上），它希望能够将/usr/include 用于系统标头。我仍然希望能够使用它，尽管我怀疑 Apple 终于抛弃了与遗留 Unix 系统兼容的最后痕迹（在某种程度上，写作是在墙上写下使 Mojave 工作所需的系统'）。在这种情况下，我可能不得不重建 GCC，以某种方式指定系统头文件的当前位置——手动抨击如何配置 GCC。
@JonathanLeffler：更新到 catalina 后，我还面临一些文件（如 stdlib.h）丢失的问题，这些文件在安装 R 包时由软件包 R 使用。我在 macOS_10.14 上尝试了和你一样的方法，但这已经不可能了。 GCC、c++ 或 /Library/Developer/CommandLineTools/usr/bin 中安装的任何内容，但 R 不知道。我能做什么？
解决此问题的一种方法是使用 Xcode 编译器——如果安装了它们，它们就知道在哪里可以找到系统头文件。接受的答案中的 CPATH 技术似乎也可以正常工作。我还没有因为“双重打字”（我知道）而在 Mac 上受苦。我让我的 iPhone 决定我已经输入了各种有趣的东西，但到目前为止，触摸木头，我的 MacBook Pro 还可以。
接受的答案让 bash5.0 编译，但现在我遇到了 make 和 make install 的问题，这似乎与fatal error: wchar.h: No such file or directory # include <wchar.h> compilation terminated 非常相似。我认为他们明天会成为一个问题。感谢您的所有努力，这很有趣且具有教育意义。

标签： c xcode macos gcc macos-catalina

【解决方案1】：

在继续之前，请确保安装 xcode 命令行工具。

xcode-select --install

其实你可以的！实际上所有的 C 头文件都可以在这个文件夹中找到：

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/

我们只需要为这个文件夹中的所有头文件创建符号链接：

/usr/local/include/

它对我有用！以下命令行将解决所有问题：

sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/

您会收到一些警告。一些标头已经存在，如下所示：

ln: /usr/local/include//tcl.h: File exists
ln: /usr/local/include//tclDecls.h: File exists
ln: /usr/local/include//tclPlatDecls.h: File exists
ln: /usr/local/include//tclTomMath.h: File exists
ln: /usr/local/include//tclTomMathDecls.h: File exists
ln: /usr/local/include//tk.h: File exists
ln: /usr/local/include//tkDecls.h: File exists
ln: /usr/local/include//tkPlatDecls.h: File exists

完全可以忽略。就是这样。

【讨论】：

是的，我想这是可能的——谢谢你的建议。它并不真正符合我对“系统卫生”的要求（例如那些重复的标题），并且/usr/local/ 目录层次结构适用于本地软件而不是系统软件。 IMO，标题应该在 /usr/include 中，而 Apple 只是一个痛苦。
有一个办法，可能行得通，你可以试试。在恢复模式下，禁用 SIP，然后以写入模式挂载/。然后填充/usr/include 文件夹。这是因为在 10.15 中，系统安装为只读模式。如果不禁用 SIP，您将无法挂载系统卷。
禁用 SIP 对我来说是不可接受的，即使作为临时措施也是如此。
这是唯一有效的方法，已经尝试了六个指南，+1
@Roy 的解决方案对我不起作用。此外，它还导致 Catalina 上的 Rcpp 出现问题。我纠正了这里描述的问题：https://stackoverflow.com/questions/64565863/rcpp-not-working-on-r-3-6-3-macos-catalina-10-15-7/64618049#64618049

【解决方案2】：

对我来说，将以下路径添加到 CPATH 解决了这个问题：

export CPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include

【讨论】：

我尝试添加 CPATH；但是，我仍然遇到同样的错误。只是想做一个简单的 cout
当我尝试这个时，它在 Mojave 下使用现在的 Xcode 11.1 构建的 GCC 9.2.0 进行了一次随意的测试——谢谢。
如果您使用的是命令行工具而不是 Xcode.app，请使用export CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/
对此的另一个变体是：#include <stdlib.h> — #include <stdio.h> — int main(void) { printf("Hello World!\n"); return EXIT_SUCCESS; }。使用序列<stdlib.h> 然后<stdio.h> 中的标头，代码无法编译；使用相反顺序的标头，代码编译时不会出现任何问题。 <stdlib.h> 有点奇怪。（编译器选项：gcc -O3 -g -std=c11 -pedantic -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith -Wwrite-strings -Wold-style-definition -Wcast-qual -Wstrict-prototypes -o trial-1 trial-1.c）GCC 是自制的 9.2.0。
@Guddu 我相信后者是前者的别名。我个人更喜欢SDKs/MacOSX.sdk，因为它应该在每次系统升级时始终指向最新的 SDK。

【解决方案3】：

TL;DR

Apple 似乎认为 /usr/include 已经走上了渡渡鸟的道路——它已经灭绝——或者它可能就像 Monty Python 的 Parrot。

使用 Apple 提供的 GCC（实际上，如版本信息所示，这就是 Clang 的任何其他名称）或 Clang 可以避免出现问题。 /usr/bin/gcc 和/usr/bin/clang 都会在以下四个目录级别找到系统库：

/Applications/Xcode.app/Contents/Developer/Platforms/…

如果您构建自己的 GCC 或其他编译器，您将（可能）需要对其进行配置以在 Xcode 应用程序目录下查找系统库。

探索

升级后，我立即运行 XCode 11.0。它想安装一些额外的组件，所以我让它这样做。但是，这并没有恢复/usr/include 或/Library 下的目录。

之前question 中的其他建议之一是运行：

xcode-select --install

这样做时，它声称它下载了命令行实用程序，并确保存在/usr/bin/gcc 和/usr/bin/clang 等。这是一个有用的步骤（尽管我之前没有明确检查它们是否存在）。

$ /usr/bin/gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$

使用/usr/bin/gcc，现在可以编译程序了：

$ make CC=/usr/bin/gcc al
co  RCS/al.c,v al.c
RCS/al.c,v  -->  al.c
revision 1.7
done
/usr/bin/gcc -I/Users/jleffler/inc -g -O3 -std=c11 -pedantic -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith  -Wold-style-definition -Wcast-qual -Wstrict-prototypes -DHAVE_MEMMEM -DHAVE_STRNDUP -DHAVE_STRNLEN  -DHAVE_GETDELIM   -o al al.c -L/Users/jleffler/lib/64  -ljl
$

但是，/usr/include 仍然丢失。现在/Library下有一个目录：

$ ls /Library/Developer
CommandLineTools  PrivateFrameworks
$ ls /Library/Developer/CommandLineTools
Library SDKs    usr
$ ls /Library/Developer/CommandLineTools/SDKs
MacOSX.sdk      MacOSX10.14.sdk MacOSX10.15.sdk
$ ls /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/
Entitlements.plist SDKSettings.json   System
Library            SDKSettings.plist  usr
$

System 和 Library 目录都不包含任何非常有前途的东西。

当一切都失败时，阅读手册

下一步 - 查找并阅读发行说明：

那里没有与此相关的信息。因此，Apple 不再支持 /usr/include 的可能性是（AFAICS，仅经过一两个小时的努力）——尽管它仍然有一个完全加载的 /usr/lib（虽然没有 /lib）。

是时候检查添加了 GCC 选项 -v 的另一个编译了（在我使用的 makefile 中，设置 UFLAGS 将选项添加到 C 编译器命令行）：

$ make UFLAGS=-v CC=/usr/bin/gcc ww
co  RCS/ww.c,v ww.c
RCS/ww.c,v  -->  ww.c
revision 4.9
done
/usr/bin/gcc -I/Users/jleffler/inc -g -O3 -std=c11 -pedantic -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith  -Wold-style-definition -Wcast-qual -Wstrict-prototypes -DHAVE_MEMMEM -DHAVE_STRNDUP -DHAVE_STRNLEN  -DHAVE_GETDELIM -v  -o ww ww.c -L/Users/jleffler/lib/64  -ljl
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.15.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name ww.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-sdk-version=10.15 -target-cpu penryn -dwarf-column-info -debug-info-kind=standalone -dwarf-version=4 -debugger-tuning=lldb -ggnu-pubnames -target-linker-version 512.4 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -I /Users/jleffler/inc -D HAVE_MEMMEM -D HAVE_STRNDUP -D HAVE_STRNLEN -D HAVE_GETDELIM -I/usr/local/include -O3 -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith -Wold-style-definition -Wcast-qual -Wstrict-prototypes -Wno-framework-include-private-from-public -Wno-atimport-in-framework-header -Wno-extra-semi-stmt -Wno-quoted-include-in-framework-header -pedantic -std=c11 -fdebug-compilation-dir /Users/jleffler/src/cmd -ferror-limit 19 -fmessage-length 110 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fobjc-runtime=macosx-10.15.0 -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /var/folders/77/zx9nk6dn7_dg4xd4stvt42v00000gn/T/ww-4cb85b.o -x c ww.c
clang -cc1 version 11.0.0 (clang-1100.0.33.8) default target x86_64-apple-darwin19.0.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Users/jleffler/inc
 /usr/local/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.15.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o ww -L/Users/jleffler/lib/64 /var/folders/77/zx9nk6dn7_dg4xd4stvt42v00000gn/T/ww-4cb85b.o -ljl -L/usr/local/lib -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/lib/darwin/libclang_rt.osx.a
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil" -o ww.dSYM ww
$

数据暴风雪中的关键信息是：

-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

这实际上是编译的“根”目录，所以下面应该有usr 和usr/include 的子目录：

$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
Entitlements.plist SDKSettings.json   System
Library            SDKSettings.plist  usr
$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr
bin     include lib     libexec share
$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
AppleTextureEncoder.h  dns_util.h             memory.h               simd
AssertMacros.h         dtrace.h               menu.h                 slapi-plugin.h
Availability.h         editline               miscfs                 spawn.h
AvailabilityInternal.h err.h                  module.modulemap       sqlite3.h
AvailabilityMacros.h   errno.h                monetary.h             sqlite3ext.h
AvailabilityVersions.h eti.h                  monitor.h              stab.h
…lots more lines…
dirent.h               mach-o                 security               xcselect.h
disktab.h              mach_debug             semaphore.h            xlocale
dispatch               machine                servers                xlocale.h
dlfcn.h                malloc                 setjmp.h               xpc
dns.h                  math.h                 sgtty.h                zconf.h
dns_sd.h               membership.h           signal.h               zlib.h
$

这表明长达一英里且完全难以记住的目录名称确实包含标准 C 和 POSIX 标头，以及 Apple 特定的附加内容。

之前的/usr/local/ 目录似乎完好无损；在-isysrootdir 下不存在的关于usr/local/include 的警告是无害的（如果没有-v 选项，则不可见）。

【讨论】：

很抱歉不能听从您的建议。我在 catalina 更新中遇到了同样的错误。使用 vscode 我无法构建 C++ 应用程序并得到 wchar.h not found 错误。我尝试包含此文件夹 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include 并且我收到其他错误，例如关于“错误：没有成员”的缺少符号在全局命名空间中命名为 'isless'"
@trojanfoe — 我更喜欢 SCCS，但在 1999 年尚不清楚 SCCS 是否会在 Y2K 后正常工作（据我所知，SCCS 并没有一个好的开源实现），所以我很不情愿地切换到 RCS。
如果有人在按照此处的步骤操作后仍然遇到此问题，请检查您是否通过 homebrew 安装了 llvm 并尝试将其完全卸载。这为我解决了。
@trojanfoe：/usr/include 擅离职守的一个问题（我的主要问题）是，如果您从源代码构建了自己的 GCC，它可能被编译以在 /usr/include 中找到系统头文件，并且因此编译失败。我想使用最新的 GCC 和 Clang。我很高兴使用 Apple 的 Clang，但我不高兴使用伪装成 GCC 的 Apple 的 Clang——它与 GCC 不同。我还没有想出一个在重新定位系统头文件的情况下构建 GCC 的方法。（我认为--with-native-system-header-dir="${XCODE_HDR}" 是答案的一部分；然而，它不是全部答案。）
@Nitza 我的评论让我大开眼界！我从自制软件安装了llvm，因为我安装了ccls。我实际上现在使用clangd，所以这些clang 构建问题在brew uninstall llvm 之后就消失了。谢谢。

【解决方案4】：

设置以下隐式 Make 变量以指向 Xcode 命令行工具 (Xcode CLI) 的标头现在所在的位置：

export CFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CCFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CXXFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CPPFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

-isysroot option 更新根文件的位置远离系统根目录/。

因此，这可确保在新位置找到常见的 /usr/* 文件。

也就是说，现在找到了/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk 处的文件。这些文件是：

Entitlements.plist 
Library
SDKSettings.json
SDKSettings.plist
System
usr

【讨论】：

在我的 makefile（以及我看到的大多数其他 makefile）中，CFLAGS 比单个选项复杂得多 — -isysroot 选项需要“除”其他设置（许多其他设置）。这里可能有一个想法的核心（传递-isysroot 选项和/Library/Developer/… 下的位置），但在准备好进入黄金时段之前需要进行一些打磨。
@JonathanLeffler 使用export CFLAGS+=-isysroot ... 将适用于该用例。这是唯一对我有用的解决方案（在 Mojave (10.14) 和 Catalina (10.15) SDK 上。即使我的 XCode 和命令行工具是最新的，我也没有每个人都在谈论的 .pkg 文件）。
@Norswap — 使用 CFLAGS=… 和 CFLAGS+=… 之间存在巨大差异。
@JonathanLeffler 同意了。我已经更新了使用+= 的答案。谢谢@Norswap。
另外，我发现将 SDKROOT 设置为相同的 sdk 值 (/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk) 对我也有效！

【解决方案5】：

我是 OSX 中 R 的 C++ 编译器的新手，我遇到了同样的问题，即在 OS 更新后 C++ 找不到标头（缺少 math.h，尽管它在那里）。我按照https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/ 的指示进行操作，但没有任何改变。

最后，在我重新安装 Xcode CLI 后它对我有用

xcode-select --install

然后按照@Coatless 的建议将标志更改为 Var：

export CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CCFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CXXFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CPPFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

【讨论】：

【解决方案6】：

在 MacOS Catalina 10.15.4 和 Xcode 版本 11.5 (11E608c) 上，我还需要更新 .zshrc 中的库路径（MacOSX.sdk 路径是新的）：

export CPATH='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include:/opt/local/include'
export LIBRARY_PATH='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib:/opt/local/lib'

【讨论】：

这是 MacOS Catalina 上的唯一要求（安装命令行工具后）。

【解决方案7】：

对我来说，效果很好：

1. xcode-select --install

2. sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/

3. export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

【讨论】：

【解决方案8】：

如果您同时安装了命令行工具和 XCode，请确保命令行工具安装的 SDK 正在实际使用中：

#查看当前sdk

$ xcrun --show-sdk-path

#更改sdk

$ sudo xcode-select -s /Library/Developer/CommandLineTools #Using CommandLineTools SDK

$ sudo xcode-select -s /Applications/Xcode.app/Contents/Developer #Using XCode.app SDK

感谢https://stackoverflow.com/a/61526989/596599 的回答。

【讨论】：

【解决方案9】：

就我而言，我似乎也使用自制软件安装了 llvm 和 gcc。当我删除这些并因此完全依赖 macOS clang 时，它可以找到标头并且编译再次工作。

【讨论】：

【解决方案10】：

简答

/Library/Developer/CommandLineTools/usr/bin/clang++ -o main main.cpp -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk

The Result

说明

在当前 macOS 版本中，c/c++ 标头在 /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/ 内搜索，而不是 /usr/include。因此，您需要使用-isysroot 选项“重置”根目录。

希望这是有道理的?。

【讨论】：

没有。这没有意义。
没有。这绝对没有任何意义

【解决方案11】：

如果使用外部 LLVM 安装，请将这些添加到您的 ~/.bash_profile

LLVM_PATH="/usr/local/opt/llvm/" # or any other path
LLVM_VERSION="11.0.0"
export PATH="$LLVM_PATH:$PATH"
export SDKROOT=$(xcrun --sdk macosx --show-sdk-path)
export LD_LIBRARY_PATH="$LLVM_PATH/lib/:$LD_LIBRARY_PATH"
export DYLD_LIBRARY_PATH="$LLVM_PATH/lib/:$DYLD_LIBRARY_PATH"
export CPATH="$LLVM_PATH/lib/clang/$LLVM_VERSION/include/"
export LDFLAGS="-L$LLVM_PATH/lib"
export CPPFLAGS="-I$LLVM_PATH/include"
export CC="$LLVM_PATH/bin/clang"
export CXX="$LLVM_PATH/bin/clang++"

（调整clang版本和外部llvm安装路径。）

然后运行source ~/.bash_profile

【讨论】：

【解决方案12】：

在遵循 Komol Nath Roy 对此问题的回答后，我的/usr/local/include 中仍然缺少

apue.h 依赖项。

我从 git 手动下载了依赖项，并将其放在 /usr/local/include

【讨论】：

标头 apue.h 来自 W Richard Stevens，Stephen A Rago Advanced Programming in the Unix Environment, 3rd Edn 2013. AFAIK，Apple 从未将其作为系统标头提供。（它不在运行 Mojave 的机器上的 /usr/include 中。）如果它曾经安装在 /usr/include 中，它可能是手动创建的，而不是由 Apple 提供的。因此，它应该已经安装在 /usr/local/include 之前。
请原谅我的幼稚问题，但我这周刚刚接触了 C++。是否在 C++ 中手动管理依赖项/标头？如果是，我应该把所有所说的依赖项/标题放在/usr/include 中吗？
Q1：或多或少。这有点取决于您的意思，但是如果您正在使用的机器上的标头不是标准的，您必须担心 C 或 C++ 的依赖项和标头。那么问题来了——标准是什么？可以给出的最佳答案是“取决于”，它取决于很多因素——包括“平台”（O/S、编译器）。 Q2 是“不，你通常不应该在/usr/include 中放任何东西”——改用/usr/local/include。一般来说，将/usr/include和/usr/lib单独留下是最安全的，而是在/usr/local下添加素材。

【解决方案13】：

解决方案比我想象的要简单。安装 clang/llvm。

brew install llvm

然后我们需要自己创建符号链接。

for f in /usr/local/Cellar/llvm/9.0.0_1/bin/clang*; do ln -s ${f} /usr/local/bin/"${f##*/}"; done

和

ln -s /usr/local/Cellar/llvm/9.0.0_1/include/c++ /usr/local/include/c++

根据你的llvm版本，修改以上命令。

现在，您可以在不传递任何自定义标志的情况下编译 C++ 程序。

clang++ hello.cpp

【讨论】：

【解决方案14】：

我尝试了 1) 手动链接 2) brew install llvm，但它们不起作用。

最后，这对我有用： https://gitmemory.com/issue/pytorch/pytorch/31190/565153503

通过设置以下环境变量：

export CC=clang
export CXX=clang++
export MACOSX_DEPLOYMENT_TARGET=10.9

【讨论】：

【解决方案15】：

就我而言，我做了数百万件事，但我认为以下步骤有助于修复 ruby 安装。

xcode-select --install
设置这些标志

export CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CCFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CXXFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CPPFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/
export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
rbenv install 2.6.3 -v

【讨论】：

【解决方案16】：

对我来说，错误是：xcrun[20873:1179298] Failed to open macho file at /Library/Developer/CommandLineTools/usr/bin/clang++ for reading: Too many levels of symbolic links

于是我打开终端并进入以下文件夹（如错误消息所述）：/Library/Developer/CommandLineTools/usr/bin/

然后我删除了名为clang++的快捷方式文件

sudo rm clang++

接下来，我复制了一个名为clang的可执行文件并将复制的文件重命名为clang++

sudo cp clang clang++

终于成功了。

【讨论】：