在OS X 10.11上构建GCC [英] Building GCC on OS X 10.11

查看:134
本文介绍了在OS X 10.11上构建GCC的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在此处使用命令行在OS X 10.11.1上构建GCC(最新版本):

Building GCC (latest revision) on OS X 10.11.1 here, using the command line:

../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

严格按照构建说明进行操作,并出现此错误:

Followed build instructions exactly, and getting this error:

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 .)

(A complete log is available at https://gist.github.com/3cb5d044533e657f4add.)

在调查了gcc/Makefile之后,似乎BUILD_CPPLIB变量不包含$(LIBICONV),因为在发生错误时它处于stage1引导程序中.相关部分前面有

After investigating gcc/Makefile, it seems that the BUILD_CPPLIB variable does not include $(LIBICONV), since it is in a stage1 bootstrap at the time of the error. The relevant section is preceded by

# 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的符号.所以这里有些不对劲.

Yet clearly the stage1 build of build/genmatch is referencing libcpp, which uses symbols from libiconv. So something is amiss here.

我该如何解决?

推荐答案

一般性讨论

在Mac OS X上构建GCC有时会遇到麻烦.多年来,我遇到了各种版本的GCC和各种版本的Mac OS X的问题.您可以在在Mac OS X上安装GCC -用于在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上未能成功.

General discussion

Building GCC on Mac OS X is an occasionally fraught process. I've had various issues with various versions of GCC and various versions of Mac OS X over the years. You can see an earlier explanation of what I did in Install GCC on Mac OS X — that was for building GCC 4.8.x on Mavericks 10.9.x (or possibly Mountain Lion 10.8.x); it also reports success building GCC 4.9.0 on Mavericks 10.9.x, but failure to do so on Yosemite 10.10.x.

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

This is an updated recipe for building GCC 5.2.0 on Mac OS X 10.11.1 El Capitan. It starts off using XCode 7.1.1 — I don't know which other versions of XCode are OK.

请注意, El Capitan 具有一项功能SIP(系统完整性保护),该功能不在优胜美地及更早版本中.这意味着您不能再在/usr下创建任意目录.我以前安装在/usr/gcc/vX.Y.Z中; El Capitan不再允许这样做.因此,主要的变化是我现在安装在/opt/gcc/v.X.Y.Z中.

Note that El Capitan has a feature SIP (System Integrity Protection) that was not in Yosemite and earlier versions. This means you cannot create arbitrary directories under /usr any more. I used to install in /usr/gcc/vX.Y.Z; that is no longer permitted in El Capitan. One major change, therefore, is that I now install in /opt/gcc/v.X.Y.Z.

我发现设置DYLD_LIBRARY_PATH是有问题的-特别是在El Capitan上.与过去的重大突破,我现在根本没有设置.请注意,脚本会将其取消设置.还要注意,该脚本将第1阶段编译器CC和CXX分别分别设置为/usr/bin/clang/usr/bin/clang++(XCode编译器).当前版本的GCC需要功能强大的C ++编译器,而不是(或同时需要)C编译器.

I've found that having DYLD_LIBRARY_PATH set is problematic — especially on El Capitan. In a major break from the past, I'm now not setting that at all. Note that the scripts unset it. Note too that the script explicitly sets the phase 1 compilers CC and CXX to /usr/bin/clang and /usr/bin/clang++ respectively (the XCode compilers). The current versions of GCC require a capable C++ compiler instead of (or as well as) a C compiler.

我偶尔会遇到libiconv的问题,但此刻我没有安装自己的版本来规避它们.同样,我有时在GCC源代码中的某些awk脚本也遇到问题.我必须对其进行破解才能使其正常运行.但是,有了GCC 5.2.0源代码的发行副本,我似乎可以直接使用现成的版本进行构建.

I have occasionally had problems with libiconv, but at the moment I've evaded them by not having my own version installed. Similarly, I've occasionally had problems with some awk scripts in the GCC source. I had to hack it/them to get it to work OK. However, with release copy of GCC 5.2.0 source, I seem to be able to build directly out of the box.

如果只有一个磁盘分区,那么接下来的时间就不重要了.如果您有多个磁盘,请确保目标目录不存在,或者确保其名称正是您想要的名称.在工作的机器上(不是Mac,而是Linux机器等),我仍将/usr/gcc/vX.Y.Z用作官方"安装位置,但是该软件最终存储在具有足够空间的任意文件系统中,例如/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中.这限制了安装的可移植性.即使您要求将其安装在/usr/gcc/vX.Y.Z中,该计算机要移动到的其他任何计算机都必须具有目录/work4/gcc/vX.Y.Z.

If you've only got a single disk partition, this next point isn't crucial. If you have multiple disks, either make sure the target directory does not exist or ensure that its name is exactly what you want. On the machines at work (not Macs but Linux machines, etc), I still use /usr/gcc/vX.Y.Z as the 'official' install location, but the software ends up in some arbitrary file system where there's enough space, such as /work4/gcc, and eventually there is a symlink such that /usr/gcc/vX.Y.Z gets to /work4/gcc/vX.Y.Z. However, it is crucial that /work4/gcc/vX.Y.Z does not exist while GCC is being compiled because it will resolve the name via realpath() or its equivalent and embed /work4/gcc/vX.Y.Z into the binaries, rather than the neutral name /usr/gcc/vX.Y.Z. This limits the portability of the installation; any other machine that it is moved to has to have a directory /work4/gcc/vX.Y.Z, even though you asked to install it in /usr/gcc/vX.Y.Z.

我必须处理GMP(5.1.3而不是6.0.0a)和ISL(0.14而不是0.15)的降级版本.更高版本的构建都给我带来了麻烦.

I had to work with down-versions of both GMP (5.1.3 instead of 6.0.0a) and ISL (0.14 instead of 0.15). The builds for the later versions both caused me trouble.

请注意,我放置了GMP,MPC,MPFR,ISL和Cloog的库代码(请参见 GCC的前提条件),以便GCC构建这些库的自己的版本.我发现这是确保GCC正确定位这些库的最简单方法.

Note that I put the library code for GMP, MPC, MPFR, ISL and Cloog (see the GCC pre-requisites) in the GCC source directory so that GCC builds its own versions of these libraries. I've found that its the simplest way to ensure that GCC locates these libraries correctly.

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

在运行2.3 GHz英特尔酷睿i7、17 GiB 1333 MHz DDR3主内存和750 GB 5400 rpm硬盘驱动器的17英寸MacBook Pro(2011年初)上,构建时间约为2h 15m. 850 MiB;构建树的大小大约为4.6 GiB –您需要足够的磁盘空间;安装的代码最终的大小为420 MiB.

Build time was about 2h 15m on a 17" MacBook Pro (early 2011) running Intel Core i7 at 2.3 GHz, with 16 GiB 1333 MHz DDR3 main memory, and a 750 GB 5400 rpm hard disk drive. The source occupies about 850 MiB; the build tree ends up at about 4.6 GiB — you need plenty of disk space. The installed code ends up at about 420 MiB.

#!/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-非空白,非注释行

Script nbncl — non-blank, non-comment lines

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

use warnings;
use strict;

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

这篇关于在OS X 10.11上构建GCC的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆