在 Mac 上构建 gcc 时遇到问题 - 找不到系统标头

Question

我在运行 OS-X High Sierra 的 Mac 上，想创建一个单独的 gcc 版本。Lemme 分享了我花了一周时间才完成的一些过程，以便对其他人有所帮助：

我创建了一个安全目录“gcc”并使用 svn 从 gcc 获取最新的源代码，它在名为“trunk”的子目录中创建。我最初在主干的顶层创建了一个名为“build”的目录。

它不会在没有 4 个依赖项的情况下编译，所以我运行 ./contrib/download 先决条件来获取它们，但它仍然无法编译，所以我分别进入这 4 个目录中的每一个并执行 ./configure, ./make 、./make install 和 ./make 检查。我做了安装部分，因为即使这些依赖项也相互依赖，所以安装似乎是确保可以找到它们的安全方法。后来我发现没有其他方法，尽管有相反的指示......

我成功地构建了依赖项 GMP、MPFR、ISL 和 MPC。然后我回到 ./build 并且 ../configure 成功了，但是构建（make）很快就失败了，说“源目录已经配置；先运行“make distclean there first”。谷歌搜索显示这是在源目录中配置时.我想也许我的主干/构建目录被认为是“在源目录中”，所以我移动了它并再次尝试，同样的事情发生了。当我尝试进入主干并输入“make distclean”时只是说没有规则使目标 distclean。

所以我想，也许是 4 个依赖目录？也许现在它们已安装，可以安全地将它们全部清除？在那里，使 distclean 工作并取出所有东西 - 甚至是我运行的测试。看起来很浪费并且需要预先安装它们，但它起作用了。

回到构建中，make 然后在 make 期间开始了一些严肃的编译工作，但崩溃说“应该包含系统头文件的目录不存在：/usr/include”。

我应该如何引导这个？我在哪里可以找到要复制到 /usr/include 中的系统头文件？以后我会遇到缺少 libc 和库的相同问题吗？另外，如果我想在不重建的情况下将其移植到新计算机上，除了可执行文件和头文件之外，我还需要复制什么？我会把它们放在哪里？

感谢您的任何建议... - 杰夫

Answer 1

我设法使用 Xcode 8.3.3 在 macOS Sierra 上巧妙地构建了 GCC。在您的系统上尝试以下操作。（如果您有较新版本的 macOS 或较新版本的 Xcode，则可能需要进行一些调整。）

先决条件

• macOS 塞拉利昂 10.12.6
• Xcode 8.3.3

细节：

$ xcode-select -p
/Users/strager/Applications/Xcode_8.3.3.app/Contents/Developer

$ clang --version                     
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Users/strager/Applications/Xcode_8.3.3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

$ as --version
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Users/strager/Applications/Xcode_8.3.3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

$ ld -v
@(#)PROGRAM:ld  PROJECT:ld64-278.4
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
LTO support using: LLVM version 8.1.0, (clang-802.0.42)
TAPI support using: Apple TAPI version 1.33.11

配置和构建

$ # Download GCC's source code.
$ git clone git://gcc.gnu.org/git/gcc.git gcc
$ # I tested the following revision (SVN r278004 from November 9, 2019):
$ (cd gcc && git checkout a9ad50cb8ec15c509d27c1dbd47b76f56d20fb3b)
$ # Download GCC's uncommon dependencies.
$ ./contrib/download_prerequisites
$ # Apply a build fix: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01109.html
$ patch -p1 <<<EOF
diff --git a/libstdc++-v3/include/bits/alloc_traits.h
b/libstdc++-v3/include/bits/alloc_traits.h
index 55211ac1d72..6ad02df16f7 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -566,7 +566,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif

   template<typename _Alloc>
-    _GLIBCXX14_CONSTEXPR void
+    _GLIBCXX14_CONSTEXPR inline void
     __alloc_on_copy(_Alloc& __one, const _Alloc& __two)
     {
       typedef allocator_traits<_Alloc> __traits;
@@ -580,7 +580,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
     }

   template<typename _Alloc>
-    constexpr _Alloc
+    constexpr inline _Alloc
     __alloc_on_copy(const _Alloc& __a)
     {
       typedef allocator_traits<_Alloc> __traits;
@@ -598,7 +598,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif

   template<typename _Alloc>
-    _GLIBCXX14_CONSTEXPR void
+    _GLIBCXX14_CONSTEXPR inline void
     __alloc_on_move(_Alloc& __one, _Alloc& __two)
     {
       typedef allocator_traits<_Alloc> __traits;
@@ -625,7 +625,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif

   template<typename _Alloc>
-    _GLIBCXX14_CONSTEXPR void
+    _GLIBCXX14_CONSTEXPR inline void
     __alloc_on_swap(_Alloc& __one, _Alloc& __two)
     {
       typedef allocator_traits<_Alloc> __traits;
EOF

$ # Configure a build directory for a 3-stage build.
$ mkdir gcc-build-release
$ cd gcc-build-release
$ ../gcc/configure \
    --disable-werror \
    --enable-checking=release \
    --enable-languages=c,c++ \
    --prefix="${PWD}/../usr" \
    --with-native-system-header-dir=/Users/strager/Applications/Xcode_8.3.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/ \
    --disable-multilib

$ # Build.
$ flags='-mmacosx-version-min=10.12 -Wa,-mmacosx-version-min=10.5 -iframework /Users/strager/Applications/Xcode_8.3.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/' ; \
    make -w -j9 BOOT_CFLAGS="${flags}" CFLAGS_FOR_TARGET="${flags}" CXXFLAGS_FOR_TARGET="${flags}"

故障排除

问题：构建失败：

应该包含系统头文件的目录不存在：/usr/include

原因：GCC 的配置脚本默认为--with-native-system-header-dir=/usr/include. 那个导演不存在。

解决方案：使用--with-native-system-header-dir=/Users/strager/Applications/Xcode_8.3.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/.

问题：链接或配置失败：

检查 C 编译器是否工作...没有
配置：错误：在`/Users/strager/tmp/Projects/gcc/build-release/x86_64-apple-darwin16.7.0/libgomp'：
配置：错误：C 编译器无法创建可执行文件

config.log 显示：

ld：找不到 -lcrt1.10.6.o 的库

或以下任何一项：

ld：找不到 -ldylib1.o 的
库 ld：找不到 -ldylib1.10.5.o 的库

原因：-mmacosx-version-min=提供给链接器驱动程序的值与Xcode 中的 SDK 不匹配。GCC 尝试链接错误的对象。

解决方案：构建阶段2和3 -mmacosx-version-min=10.12（对于Xcode中8.3.3的MacOSX10.12.sdk）使用BOOT_CFLAGS，CFLAGS_FOR_TARGET以及CXXFLAGS_FOR_TARGET化妆变量。

问题：libstdc++.6.dylib 无法链接：

0 0x1059a453b __assert_rtn + 129
1 0x1059a940a mach_o::relocatable::CUSection::personalityName(mach_o::relocatable::Parser&, macho_relocation_info > const*) + 170
2 0x1059a940a mach_o::relocatable::CUSection::personalityName ::Parser&, unsigned int, mach_o::relocatable::CUSection::Info*) + 306
3 0x1059b666b mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions const&) + 695
4 0x1059af1c9 mach_o relocatable::Parser::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 261
5 0x1059d9758 archive::File:: makeObjectFileForMember(archive::File::Entry const*) const + 748
6 0x1059d8b8c archive::File::forEachAtom(ld::File::AtomHandler&) const + 238
7 0x1059f2955 ld::tool::InputFiles::forEachInitialAtom(ld::File::AtomHandler&, ld::Internal&) + 533
8 0x1059fe49c ld::tool::Resolver::resolve() + 44
9 0x1059a5289 main + 725
在以下
位置创建了链接器快照：/ tmp/libstdc++.6.dylib-2019-10-13-002048.ld-snapshot
ld失败: ((parser.sectionForAddress(personalityAddr)->type() == ld::Section::typeCode) &&“__compact_unwind 部分中的个性列不是指向函数的指针”），函数personalityName，文件/Library/Caches/com .apple.xbs/Sources/ld64/ld64-278.4/src/ld/parsers/macho_relocatable_file.cpp，第 5128 行
。collect2：错误：ld 返回 1 个退出状态

原因：LLVM 的汇编程序 ( as) 生成__compact_unwind部分。尽管GCC 与 链接-no_compact_unwind，ld64 验证这些__compact_unwind部分。数据格式错误（导致未知），因此链接器会抱怨。

解决方法：告诉汇编程序不会产生__compact_unwind使用部分-Wa,-mmacos-version-min=10.5使用阶段2和3 BOOT_CFLAGS，CFLAGS_FOR_TARGET和CXXFLAGS_FOR_TARGET化妆变量。

问题：libstdc++.6.dylib 无法链接：

对于架构x86_64的未定义的符号：
“__ZSt15__alloc_on_copyISaIcEEvRT_RKS1_”，从引用：
__ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6assignERKS4_中的libstdc ++一个（字符串inst.o）。
“__ZSt15__alloc_on_moveISaIcEEvRT_S2_”，从引用：
。__ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_中的libstdc ++一个（字符串inst.o）
“__ZSt15__alloc_on_swapISaIcEEvRT_S2_”，从参考：
__ZN9__gnu_cxx14__alloc_traitsISaIcEcE10_S_on_swapERS1_S3_ 在 libstdc++.a(string-inst.o)
ld：找不到架构 x86_64
collect2 的符号：错误：ld 返回 1 退出状态

原因：-fno-implicit-templates导致不创建这些符号，即使它们是必要的。

解决方案：内联标记函数模板。

问题：ASAN (libsanitizer) 无法编译：

在 ../../../../gcc/libsanitizer/asan/asan_malloc_mac.cpp:64 包含的文件中：
../../../../ gcc/ libsanitizer/ sanitizer_common/ sanitizer_malloc_mac.inc： 20:10：致命错误：CoreFoundation/CFBase.h：没有那个文件或目录
20 | ＃包括

原因：GCC 没有被告知 CoreFoundation 在 Xcode 的 SDK 中的位置。

解决方案：构建阶段2和3与-iframework .../SDKs/MacOSX.sdk/System/Library/Frameworks使用BOOT_CFLAGS，CFLAGS_FOR_TARGET以及CXXFLAGS_FOR_TARGET化妆变量。

Answer 2

好吧，我上面提到的所有内容都不起作用 - gcc 构建标志都不起作用。但我最终以一种简单的方式修复了我的系统：问题是你需要 gcc 来制作 gcc，而我什至无法执行“brew install gcc”——它会因损坏的 C++ 库而崩溃。

但后来我意识到 XCode 带有一个安全、完全独立（如果已经过时）的 clang/llvm 工具链 - 它实际上就像拥有一个 docker。为了找到它放置所有内容的确切位置，我使用了该命令xcodebuild -find x（将“x”替换为make、gcc、clang等）。我发现 gcc 需要构建的所有东西都在这里：

export PATH=/Applications/Xcode.app/Contents/Developer/usr/bin:$PATH

一旦进入我的路径，make 就去那里并使用 XCode 的 gcc，它足够新，可以构建或安装现代 gcc，所以我可以这样做：

brew reinstall gcc

天哪，我终于得到了一个功能齐全的 gcc 工具链。Brew 把它放进去/usr/local/bin等等。

这比我想象的要难。既然你需要 gcc 来制作 gcc，那么它是如何产生的呢？;)