在非标准的位置build立gcc-4.3.4时遇到困难

我需要在非标准位置(NFS挂载)中构buildgcc-4.3.4。 我configuration了:

../gcc-4.3.4/configure --prefix={install dir} --with-gmp={install dir} --with-mpfr={install dir} --with-local-prefix={install dir} --disable-shared 

我跑了make -j1 。 但我不断收到:

 checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile 

x86_64-unknown-linux-gnu/libgcc/config.log ,我可以看到:

 /home/panthdev/apps/gcc-4.3.4-compliant/compiler/objdir/./gcc/cc1: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory 

libmpfr.so.1{install dir}/lib 。 另外,如果我将LD_LIBRARY_PATH设置为{install dir}/lib ,那么它会findlibmpfr.so.1但是config.log开始抱怨:

 /tmp/cce9YhFK.s: Assembler messages: /tmp/cce9YhFK.s:16: Error: bad register name `%rbp' /tmp/cce9YhFK.s:18: Error: bad register name `%rsp' 

正如我在这里读到的,你有32位binutils,而gcc正在尝试做一个64位版本。 确保你的binutils和gcc具有相同的配置。

你应该尝试使用--with-sysroot而不是--prefix

在GCC 4.5.2配置脚本(我有这个可用,但不是4.3.4),在4500行(15.5K行)左右,有一节:

 rm -f conftest.$ac_ext EXEEXT=$ac_cv_exeext ac_exeext=$EXEEXT { $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object files" >&5 $as_echo_n "checking for suffix of object files... " >&6; } if test "${ac_cv_objext+set}" = set; then : $as_echo_n "(cached) " >&6 else cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ int main () { ; return 0; } _ACEOF rm -f conftest.o conftest.obj if { { ac_try="$ac_compile" case "(($ac_try" in *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; *) ac_try_echo=$ac_try;; esac eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\"" $as_echo "$ac_try_echo"; } >&5 (eval "$ac_compile") 2>&5 ac_status=$? $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5 test $ac_status = 0; }; then : for ac_file in conftest.o conftest.obj conftest.*; do test -f "$ac_file" || continue; case $ac_file in *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map | *.inf | *.dSYM ) ;; *) ac_cv_objext=`expr "$ac_file" : '.*\.\(.*\)'` break;; esac done else $as_echo "$as_me: failed program was:" >&5 sed 's/^/| /' conftest.$ac_ext >&5 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;} as_fn_error "cannot compute suffix of object files: cannot compile See \`config.log' for more details." "$LINENO" 5; } fi rm -f conftest.$ac_cv_objext conftest.$ac_ext fi 

基本上,脚本试图编译“conftest.c”,并试图找到创建的对象文件的扩展名 – 出于某种原因,编译器不会创建conftest.o。

这不是它在编译器上做的第一个测试,所以在你的环境中似乎有些奇怪的事情发生。

多年来我已经构建了多次GCC – 在Solaris和MacOS X上 – 我一直使用--prefix选项。 这不是问题。 GMP,MPFR,MPC目录是必要的; 你不熟悉的唯一选项是--with-local-prefix

你是否指定了bootstrap编译器? 考虑尝试使用CC=/usr/bin/gcc或类似的东西来尝试当前的配置行,在您的机器上标识一个完全正常的编译器。 我不相信会解决这个问题,但是编译器的行为方式或者它产生的对象文件扩展名有一些有趣的地方。 我假设在磁盘系统上有几GB的空闲空间? 你会需要的。


打开“ 安装GCC:配置 ”页面,我发现:

--with-local-prefix=dirname

指定本地包含文件的安装目录。 默认是/usr/local 。 如果您希望编译器搜索本地安装的头文件的目录dirname /include而不是/usr/local/include请指定此选项。

只有当您的站点具有不同的约定(而不是/usr/local )才能放置站点特定的文件时,您应该指定--with-local-prefix

--with-local-prefix的默认值是/usr/local而不考虑--prefix的值。 指定--prefix对GCC搜索本地头文件的目录没有影响。 这看起来可能违反直觉,但实际上这是合乎逻辑的。

--prefix的目的是指定GCC的安装位置。 /usr/local/include的本地头文件(如果您将该文件放在该目录中)不属于GCC。 他们是其他计划的一部分 – 也许还有其他计划。 (GCC将自己的头文件安装在基于--prefix值的另一个目录中。)

本地前缀include目录和GCC-prefix include目录都是GCC的“system include”目录的一部分。 虽然这两个目录不是固定的,但需要按正确的顺序搜索include_next指令。 在GCC-prefix包含目录之前搜索本地前缀包含目录。 系统的另一个特点是目录是在这些目录中关闭迂腐的警告。

一些autoconf宏将-I目录选项添加到编译器命令行中,以确保搜索包含已安装软件包标题的目录。 当目录是GCC的系统包含目录之一时,GCC将忽略该选项,以便继续以正确的顺序处理系统目录。 这可能会导致搜索顺序与指定的不同,但目录仍将被搜索。

GCC使用GCC_EXEC_PREFIX自动搜索普通的库。 因此,当GCC和软件包使用相同的安装前缀时,GCC将自动搜索头文件和库文件。 这提供了易于使用的配置。 GCC的行为方式类似于在/ usr中作为系统编译器安装的方式。

需要安装多个版本的GCC的网站可能不希望使用上述简单的配置。 可以使用–program-prefix,–program-suffix和–program-transform-name选项将多个版本安装到单个目录中,但使用不同的前缀可能会更简单,而–with- local-prefix选项来指定每个版本的站点特定文件的位置。 那么用户需要明确指定本地站点库的位置(例如,使用LIBRARY_PATH)。

--with-local-prefix--prefix可以使用相同的值,前提是它不是/usr 。 这可以用来避免默认搜索/usr/local/include

不要将/usr指定为--with-local-prefix ! 用于--with-local-prefix的目录不能包含任何系统的标准头文件。 如果包含它们,某些程序会被编译错误(包括某些目标上的GNU Emacs),因为这会覆盖和取消fixincludes脚本所做的头文件更正。

迹象表明,使用这个选项的人会根据错误的想法来使用它。 人们使用它,就好像它指定在哪里安装GCC的一部分一样。 也许他们做了这个假设,因为安装GCC创建目录。

你确定你正确的使用了吗? 你可能是因为你必须搜索找到选项 – ../gcc-4.xy/configure --help没有提到这个选项。