Question

使用命令行在OS X 10.11.1上构建GCC（最新版本）：

../gccx/configure --with-gmp="/opt/local" --with-mpfr="/opt/local" \
    --with-mpc="/opt/local" --with-libiconv-prefix="/opt/local" --with-pkgversion="GCCX" \
    --program-transform-name='s/^gcc$/gccx/; s/^g++$/g++x/' --enable-languages=c

完全遵循构建说明，并收到此错误：

g++ -std=gnu++98   -g  -DIN_GCC    -fno-strict-aliasing
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -Wl,-no_pie   -o build/genmatch \
        build/genmatch.o ../build-x86_64-apple-darwin15.0.0/libcpp/libcpp.a build/errors.o build/vec.o build/hash-table.o ../build-x86_64-apple-darwin15.0.0/libiberty/libiberty.a Undefined symbols for architecture x86_64:  "_iconv", referenced from:
     convert_using_iconv(void*, unsigned char const*, unsigned long, _cpp_strbuf*) in libcpp.a(charset.o)
    (maybe you meant: __Z14cpp_init_iconvP10cpp_reader, __cpp_destroy_iconv )  "_iconv_close", referenced from:
     __cpp_destroy_iconv in libcpp.a(charset.o)
     __cpp_convert_input in libcpp.a(charset.o)  "_iconv_open", referenced from:
     init_iconv_desc(cpp_reader*, char const*, char const*) in libcpp.a(charset.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [build/genmatch] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make:
*** [all] Error 2

（https://gist.github.com/3cb5d044533e657f4add提供完整的日志。）

在调查gcc/Makefile之后，似乎BUILD_CPPLIB变量不包含$（LIBICONV），因为它在错误发生时处于stage1引导程序中。

之前是相关部分

# For stage1 and when cross-compiling use the build libcpp which is
# built with NLS disabled.  For stage2+ use the host library and
# its dependencies.

很明显，build/genmatch的stage1版本引用了libcpp，它使用了libiconv中的符号。所以这里有些不妥。

我该如何解决？

Answer 1

一般性讨论

在Mac OS X上构建GCC偶尔会出现问题。多年来，我对各种版本的GCC和各种版本的Mac OS X都有各种各样的问题。你可以看到我在Install GCC on Mac OS X中所做的事情的早期解释 - 那是用于在Mavericks 10.9.x（或可能是Mountain Lion 10.8.x）上建立GCC 4.8.x;它还报告了在Mavericks 10.9.x上成功建立GCC 4.9.0，但未能在Yosemite 10.10.x上建立。

这是在Mac OS X 10.11.1 El Capitan上构建GCC 5.2.0的更新配方。它开始使用XCode 7.1.1 - 我不知道哪些其他版本的XCode都可以。

请注意，El Capitan具有SIP（系统完整性保护）功能，该功能不在Yosemite和早期版本中。这意味着您无法再在/usr下创建任意目录。我以前安装在/usr/gcc/vX.Y.Z; El Capitan不再允许这样做。因此，一个重大变化是我现在安装在/opt/gcc/v.X.Y.Z。

我发现设置DYLD_LIBRARY_PATH是有问题的 - 特别是在El Capitan上。在与过去的重大突破中，我现在根本没有设定。请注意脚本取消设置它。另请注意，脚本分别将阶段1编译器CC和CXX分别设置为/usr/bin/clang和/usr/bin/clang++（XCode编译器）。当前版本的GCC需要一个功能强大的C ++编译器，而不是（或者除了）C编译器。

我偶尔会遇到libiconv的问题，但是目前我还没有安装自己的版本，因此避开了它们。同样，我偶尔会遇到GCC源代码中某些awk脚本的问题。我不得不破解它/它们让它工作正常。但是，对于GCC 5.2.0源代码的发布副本，我似乎能够直接开箱即用。

如果您只有一个磁盘分区，那么下一点并不重要。如果您有多个磁盘，请确保目标目录不存在或确保其名称正是您想要的。在工作的机器上（不是Mac机器，而是Linux机器等），我仍然使用/usr/gcc/vX.Y.Z作为官员＆＃39;安装位置，但软件最终会出现在有足够空间的任意文件系统中，例如/work4/gcc，最终会有一个符号链接，/usr/gcc/vX.Y.Z到达/work4/gcc/vX.Y.Z 。但是，在编译GCC时，/work4/gcc/vX.Y.Z不存在至关重要，因为它将通过realpath()或其等价物解析名称并将/work4/gcc/vX.Y.Z嵌入到二进制文件中，而不是中性名称/usr/gcc/vX.Y.Z。这限制了安装的便携性;移动到的任何其他计算机都必须有一个目录/work4/gcc/vX.Y.Z，即使您要求在/usr/gcc/vX.Y.Z中安装它。

使用XCode 7.1.1在Mac OS X 10.11.1上编译GCC 5.2.0

我不得不使用GMP（5.1.3而不是6.0.0a）和ISL（0.14而不是0.15）的缩减版本。后期版本的构建都给我带来了麻烦。

请注意，我将GMP，MPC，MPFR，ISL和Cloog的库代码（请参阅GCC pre-requisites）放在GCC源目录中，以便GCC构建自己的这些库版本。我发现它是确保GCC正确定位这些库的最简单方法。

目标目录：/opt/gcc/v5.2.0

17＆＃34;建造时间约为2小时15分钟。 MacBook Pro（2011年初）以2.3 GHz运行Intel Core i7，具有16 GiB 1333 MHz DDR3主内存和750 GB 5400 rpm硬盘驱动器。该来源约占850 MiB;构建树最终大约4.6 GiB - 你需要足够的磁盘空间。安装的代码最终大约为420 MiB。

使用的脚本 - `extract-gcc-5.2.0.sh`

#!/bin/bash

unset DYLD_LIBRARY_PATH

TAR=tar
VER_NUM=5.2.0
GCC_VER=gcc-${VER_NUM}
TGT_BASE=/opt/gcc
TGT_DIR=${TGT_BASE}/v${VER_NUM}
CC=/usr/bin/clang
CXX=/usr/bin/clang++

extract() {
    echo "Extract $1"
    $TAR -xf $1
}

if [ ! -d "$GCC_VER" ]
then extract ${GCC_VER}.tar.bz2 || exit 1
fi

(
cd ${GCC_VER} || exit

nbncl <<EOF |
    cloog 0.18.1 tar.gz 
    gmp 5.1.3 tar.xz 
#   gmp 6.0.0 tar.lz 
    isl 0.14 tar.bz2 
#    isl 0.15 tar.bz2 
    mpc 1.0.3 tar.gz 
    mpfr 3.1.3 tar.xz
EOF

while read file vrsn extn
do
    tarfile="../$file-$vrsn.$extn"
    if [ ! -f "$tarfile" ]
    then echo "Cannot find $tarfile" >&2; exit 1;
    fi
    if [ ! -d "$file-$vrsn" ]
    then
        (
        set -x
        extract "$tarfile" &&
        ln -s "$file-$vrsn" "$file"
        ) || exit 1
    fi
done
)

if [ $? = 0 ]
then
    mkdir ${GCC_VER}-obj
    cd ${GCC_VER}-obj
    ../${GCC_VER}/configure --prefix="${TGT_DIR}" \
        CC="${CC}" \
        CXX="${CXX}"
    make -j8 bootstrap
fi

脚本`nbncl` - 非空白，非注释行

#!/usr/bin/env perl
#
# Non-blank, non-comment lines only

use warnings;
use strict;

while (<>)
{
    chomp;
    s/\s+$//;
    s/\s*#.*$//;
    print "$_\n" unless /^$/;
}

Answer 2

对于它的价值，MacPorts拥有所有最新版本的端口，这些端口应该足以让所有人（谁知道如何编码！）阅读谁不想安装MacPorts但更喜欢安装其他方面提到的各种依赖关系。

gcc 6.3.0端口略有调整的个人版本： https://github.com/RJVB/macstrop/blob/master/lang/gcc6/Portfile

我之所以提到一个（并且发布此答案）的原因是这个经过调整的版本显示了如何让G ++使用libc ++而不是libstdc ++。这是能够使用G ++作为clang ++的真正替代品的特权，可以在不担心C ++运行时不兼容的情况下使用它。这个补丁允许我使用g ++来构建KDE（KF5）代码，并针对Qt5和使用各种clang编译器版本构建的KF5框架运行它。（补丁文件位于... / gcc6 / files。）

可能有助于解释链接文件的Tcl代码的一些解释：

忽略任何特定于$ subport ==＆＃34; libgcc＆＃34;。

的内容

正如您所看到的，您需要gmp，mpc，mpfr和isl（如果您自己安装，其他依赖项应该没有意义。）

configure.args表达式构造配置脚本的参数列表，configure.env和build.env为configure和build（make）命令添加环境变量。这里的许多配置选项都是为了确保构建使用来自MacPorts的依赖项，但如果您想要或必须使用不受SIP控制且未包含在标准PATH中的位置，则可能也需要它们。定义（当通过重置路径的进程调用时，编译器仍然应该工作。）

配置和构建在位于源目录旁边的构建目录中完成，这使得很容易重新开始或只是清理而不丢弃源。在配置步骤之后，使用＆＃34; make bootstrap-lean＆＃34;完成构建。 - 仍然在该构建目录中创建大约1.7Gb的数据。

Answer 3

首先，请看Jonathan Leffler的完整答案。我在这里有一些建议。

gcc配置和构建过程需要找到系统的本机头文件和C运行时库。更新的，基于clang的Xcode版本隐藏了这些，而旧版本的gcc似乎不知道如何找到它们。要完全构建gcc 4.6，我必须创建这些符号链接：

ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include /usr
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/dylib1.10.5.o /usr/local/lib
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o /usr/local/lib
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/bundle1.o /usr/local/lib

您的里程可能略有不同：请注意/Applications/Xcode.app/Contents下方的路径名中包含各种版本号，这些版本号在您的系统中可能会有所不同。

（如果像Jonathan所描述的那样，最新版本的MacOS不允许您在/usr中放置任何内容，则可能需要在/usr/include中创建/usr/local/include符号链接，而不是，我怀疑这也会奏效。）

此外，这在其他地方也有提及，但这是一个不寻常的要求，容易被忽视：不要尝试在自己的源代码树中构建gcc 。始终创建一个构建目录，该目录是您在其中提取gcc源的目录中的并行兄弟，而不是下面的子项。也就是说，不执行此操作：

tar xzf gcc-x.y.z.tar.bz2
cd gcc-x.y.z       # WRONG
mkdir build
cd build
../configure       # WRONG
make

相反，这样做：

tar xzf gcc-x.y.z.tar.bz2
mkdir build
cd build
../gcc-x.y.z/configure
make

这是违反直觉的，我知道，并不是很多其他软件包的工作方式，但它肯定适用于gcc，而且这是推荐的方法。

另一点：如果你发现你的构建失败了，因为你不正确地配置它，那么你必须用不同的选项重新运行configure，删除整个构建目录并从头开始更安全。有时配置和构建系统，但似乎不是100％可靠，在这种情况下检测可能需要重建的内容。（删除和重新开始是令人沮丧的，我同意，但同样，从长远来看，它确实可以节省时间。）

最后，如果您正在尝试构建交叉编译器，请参阅install gcc 4.6.1 on OS X 10.11上的一些其他建议和评论。

在OS X 10.11上构建GCC

3 个答案:

一般性讨论

使用XCode 7.1.1在Mac OS X 10.11.1上编译GCC 5.2.0

使用的脚本 - `extract-gcc-5.2.0.sh`

脚本`nbncl` - 非空白，非注释行

在OS X 10.11上构建GCC

3 个答案:

一般性讨论

使用XCode 7.1.1在Mac OS X 10.11.1上编译GCC 5.2.0

使用的脚本 - extract-gcc-5.2.0.sh

脚本nbncl - 非空白，非注释行

使用的脚本 - `extract-gcc-5.2.0.sh`

脚本`nbncl` - 非空白，非注释行