我在Mac上运行OS-X High Sierra，想创建一个单独的gcc构建。让我分享一下我花了一周时间完成的过程，这样它将帮助其他人：

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

如果没有这4个依赖项，它就无法编译，所以我运行了/contrib/download获取它们的先决条件，但它仍然无法编译，所以我分别进入了这4个目录中的每一个，并进行了编译/配置/make/进行安装，以及/检查一下。我做了安装部分，因为即使是这些依赖关系也相互依赖，所以安装似乎是确保可以找到它们的安全方法。后来我发现没有其他办法，尽管有相反的指示。。。

我成功地构建了依赖关系GMP、MPFR、ISL和MPC。然后我又回到了/build和/配置成功，但是build(make)很快就失败了，说"源目录已经配置好了；先运行"make-distclean"。谷歌搜索显示这是你在源目录中配置的时候。我想我的trunk/build目录可能被认为是"在源目录"，所以我移动了它，再试了一次，同样的事情也发生了。当我试图进入trunk并键入"make-dist clean"只是说没有规则使目标distclean。

所以我想，也许是4个依赖目录？也许现在已经安装了，可以安全地对它们进行蒸馏？在那里，make distclean工作了，并删除了所有内容，甚至包括我运行的测试。看起来很浪费，需要预先制作安装，但它起到了作用。

在构建过程中，make开始了一些严肃的编译工作，但崩溃时说"应该包含系统头的目录不存在：/usr/include"。

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

谢谢你的建议。。。-Jeff

我用Xcode 8.3.3在macOS Sierra上成功地构建了GCC。在您的系统上尝试以下操作。(如果你有更新版本的macOS或更新版本的Xcode，你可能需要进行一些调整。)

先决条件

macOS Sierra 10.12.6
X代码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编译器是否工作。。。no
配置：错误：在`/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：找不到-ldylib.10.5.o的库

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

解决方案：使用BOOT_CFLAGS、CFLAGS_FOR_TARGET和CXXFLAGS_FOR_TARGET生成变量，使用-mmacosx-version-min=10.12构建阶段2和阶段3(对于Xcode 8.3.3的MacOSX10.12.sdk)。

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

0 0x1059a453b __assert_rtn+129
1 0x1059a940 a mach_o:：可重定位：：CUSection:：personalityName(mach_o：：可重测：：：Parser&，macho_reocation_info>const*)+170
2 0x1059b8c2e mach_o：可重置：：CUSection：：parse可重定位：：分析器：：解析(mach_o:：可重定位：：ParserOptions const&ld:：File:：AtomHandler&)const+238
7 0x1059f2955 ld:：tool:：InputFiles:：forEachInitialAtom地址部分(个人地址)->type()==ld:：Section:：typeCode)&amp；"__compact_unwind部分中的personality列不是指向函数的指针")，函数personalityName，file/Library/Caches/com.apple.xbs/Sources/ld64/ld64-278.4/src/ld/parsers/macho_reloadable_file.cpp，第5128行。
collect2:错误：ld返回1退出状态

原因：LLVM的汇编程序(as)生成__compact_unwind部分。尽管GCC与-no_compact_unwind链接，但ld64验证了__compact_unwind部分。数据格式不正确(导致未知)，因此链接器会抱怨。

解决方案：告诉汇编程序不要为使用BOOT_CFLAGS、CFLAGS_FOR_TARGET和CXXFLAGS_FOR_TARGET生成变量的第2和第3阶段使用-Wa,-mmacos-version-min=10.5生成__compact_unwind节。

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

体系结构x86_64的未定义符号：
"__ZSt15__alloc_on_copyISaIcEEvRT_RKS1_"，引用自libstdc++.a中的__ZNSt7_cxx1112basic_stringIcSt11char_traitsIcESaIcEE6assignERKS4_，引用自：
__ZNSt7_cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS_在libstdc++.a中(字符串-inst.o)
"__ZSt15__alloc_on_swapISaIcEEvRT_S2_ 1退出状态

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

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

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

包含在../../../..中的文件中/gcc/libsantizer/asan/asan_malloc_mac.cpp:64:
../../../gcc/libsintizer/ssantir_common/ssantier_malloc_mac.inc:20:10:致命错误：CoreFoundation/CFBase.h：没有这样的文件或目录
20|#包括

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

解决方案：使用BOOT_CFLAGS、CFLAGS_FOR_TARGET和CXXFLAGS_FOR_TARGET生成变量，使用-iframework .../SDKs/MacOSX.sdk/System/Library/Frameworks构建阶段2和阶段3。

Paul Silistenu有一篇很棒的博客文章详细描述了这个过程：在macOS Mojave上编译GCC 9。

简短的版本是：

1) macOS 10.14 Mojave移动了系统标题，这也是从源代码构建GCC很棘手的原因之一。然而，苹果提供了一个安装程序来替换它们。

cd /Library/Developer/CommandLineTools/Packages/
open .

这将在Finder中打开一个窗口，安装软件包。请注意，这并不能保证在未来的操作系统更新中会出现。

2) 建立依赖关系：

GNU GMP
MPFR
MPC
ISL

每一个都很简单，不需要任何特殊的东西(但按此顺序安装)。

3) 博客文章推荐了这种配置(假设版本为9.1)。您可以将依赖项放在其他位置，只需指定位置即可。

mkdir build && cd build
../configure --prefix=/usr/local/gcc-9.1 
--enable-checking=release 
--with-gmp=/usr/local/gcc-9.1 
--with-mpfr=/usr/local/gcc-9.1 
--with-mpc=/usr/local/gcc-9.1 
--enable-languages=c,c++,fortran 
--with-isl=/usr/local/gcc-9.1 
--program-suffix=-9.1

程序后缀是可选的，但对这个编译器的"特殊情况"很好，以免将其与clang混淆。

这些是经验丰富的用户的简明说明；请参阅博客文章，了解更多详细的导游信息。

好吧，我上面提到的一切都不起作用——gcc构建标志都不起。但我最终用一种简单的方式修复了我的系统：问题是你需要gcc来制作gcc，而我甚至无法进行brew安装gcc——它会与损坏的C++库一起崩溃。

但后来我意识到XCode附带了一个安全、完全独立(如果已经过时)的clang/lilvm工具链——这实际上就像有一个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，它是如何产生的？；)

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

先决条件

配置和构建

故障排除

相关内容

最新更新

热门标签：