isl导致编译gcc-8.1出现错误

尝试在我自己的机器(acer ubuntu16.04)上编译gcc-8.1
系统缺少gcc-8.1的四个依赖:gmp,mpfr,mpc,isl
于是编译安装了gmp-6.1.2,isl-0.20,mpc-1.0.1,mpfr-3.1.6于/home/lb/workspace/com路径下

编译时过程如下:
(1),configure

../gcc-8.1.0/configure --prefix=/home/lb/workspace/com --with-gmp=/home/lb/workspace/com --with-mpfr=/home/lb/workspace/com --with-mpc=/home/lb/workspace/com  --with-isl=/home/lb/workspace/com

报错:缺少isl

但是明明指定了isl的安装路径,去该路径下(/home/lb/workspace/com/include)检查是否有isl的头文件:发现所有的isl头文件都单独放置于/home/lb/workspace/com/include/isl下,以为需要再单独指定isl的头文件;

../gcc-8.1.0/configure --prefix=/home/lb/workspace/com --with-gmp=/home/lb/workspace/com --with-mpfr=/home/lb/workspace/com --with-mpc=/home/lb/workspace/com  --with-isl=/home/lb/workspace/com --with-isl-include=/home/lb/workspace/com/include/isl

成功
(2)make

 make -j4

报错:

g++ -std=gnu++98 -fno-PIE -c  -DIN_GCC_FRONTEND -g -DIN_GCC     -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 -I. -Ic -I../../gcc-8.1.0/gcc -I../../gcc-8.1.0/gcc/c -I../../gcc-8.1.0/gcc/../include -I../../gcc-8.1.0/gcc/../libcpp/include -I/home/lb/workspace/com/include -I/home/lb/workspace/com/include -I/home/lb/workspace/com/include  -I../../gcc-8.1.0/gcc/../libdecnumber -I../../gcc-8.1.0/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc-8.1.0/gcc/../libbacktrace -I/home/lb/workspace/com/include/isl  -o c/c-lang.o -MT c/c-lang.o -MMD -MP -MF c/.deps/c-lang.TPo ../../gcc-8.1.0/gcc/c/c-lang.cIn file included from ../../gcc-8.1.0/gcc/system.h:528:0,from ../../gcc-8.1.0/gcc/c/c-lang.c:22:/usr/include/inttypes.h:290:8: error: ‘intmax_t’ does not name a typeextern intmax_t imaxabs (intmax_t __n) __THROW __attribute__ ((__const__));^/usr/include/inttypes.h:293:27: error: ‘intmax_t’ was not declared in this scopeextern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom)^/usr/include/inttypes.h:293:45: error: ‘intmax_t’ was not declared in this scopeextern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom)

仔细分析发现,是系统头文件中/usr/include/inttypes.h报错:一个或者多个需要在该头文件里面使用的变量类型(intmax_t),没有定义,这个变量类型在该头文件里面肯定是没有的,而是定义在了stdint.h中,这说明stdint.h没有被include进入c-lang.c中来,原因有可能是宏定义导致,做实验,发现并不是如此,确实有include stdint.h,但是系统的/usr/include/stdint.h确实没有被include进入,这就说明了有其他的stdint.h include进入代码中,那么一定是前面的那几个依赖中有stdint.h,检查发现在isl中有stdint.h:/home/lb/workspace/com/include/isl/stdint.h;而里面代码只有#include <stdint.h>这一行,可能是想再include系统的stdint.h,既然会再include系统stdint.h,那就应该没有问题啊!然而并不会再include系统的stdint.h,而是又会include它自己,然后循环下去(编译器能发现这种无限循环的发生,并终止),之所以会再include自己,是因为在编译的时候的编译选项(上面的那个)-I/home/lb/workspace/com/include/isl指定了这个isl的路径下面也成为搜索头文件的路径,并且优先级很高,导致编译器在找stdint.h时,会使用这个isl路径下的stdint.h而不是系统的,当发现这里面的代码(#include <stdint.h>)后又再以同样的方法include 该路径的stdint.h;
那么问题来了,怎么会这样!isl有问题,还是在编译gcc的时候引用isl的方法有问题;先做个实现:将isl/stdint.h重命名防止编译的时候用到它,再继续编译,发现这个编译过了,但是后续又报错:

#include <isl/stdint.h> no such file!!

这下就明白了,确实是在编译时引用stdint.h的方式有问题!引用isl的中stdint.h应该是"#include <isl/stdint.h>",也就是说引用isl的头文件的时候,就应该以/home/lb/workspace/com/include/为路径,也就是说上面的编译选项中,-I/home/lb/workspace/com/include/is/是有问题的;难道我在configure的时候指定的变量:–with-isl-include=/home/lb/workspace/com/include/isl有问题?那该怎么设置isl啊?算了试着删除这个变量再试下吧!发现configure成功了!再make编译,这个问题也自然解决了!而第一次configure的时候之所以还提示没有找到合适isl恐怕是因为编译残留吧!

继续编译

make -j4

又报错:

g++ -std=gnu++98 -fno-PIE -c   -g -DIN_GCC     -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 -I. -I. -I../../gcc-8.1.0/gcc -I../../gcc-8.1.0/gcc/. -I../../gcc-8.1.0/gcc/../include -I../../gcc-8.1.0/gcc/../libcpp/include -I/home/lb/workspace/com/include -I/home/lb/workspace/com/include -I/home/lb/workspace/com/include  -I../../gcc-8.1.0/gcc/../libdecnumber -I../../gcc-8.1.0/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc-8.1.0/gcc/../libbacktrace -I/home/lb/workspace/com/include  -o graphite-optimize-isl.o -MT graphite-optimize-isl.o -MMD -MP -MF ./.deps/graphite-optimize-isl.TPo ../../gcc-8.1.0/gcc/graphite-optimize-isl.c../../gcc-8.1.0/gcc/graphite-optimize-isl.c: In function ‘isl_schedule_node* get_schedule_for_node_st(isl_schedule_node*, void*)’:../../gcc-8.1.0/gcc/graphite-optimize-isl.c:58:52: error: ‘isl_space_dim’ was not declared in this scope

错误分析:在编译gcc-8.1.0/gcc/graphite-optimize-isl.c的时候找不到若干变量类型"isl_schedule_node",很显然这些变量类型定义在isl中,检查发现在isl/space.h中(/home/lb/workspace/com/include/isl/space.h),有可能是和上面提到的相同原因,通过改变上面的编译选项(编译选项中加入-E)进行"只预编译"来检查发现在编译没有include "space.h"从而导致找不到这些变量类型的声明或者定义;至于为什么在编译的时候没有include “space.h”,有可能是宏定义控制的!所以可以找一下graphite-optimize-isl.c以及它直接或者间接include的所有头文件里面是否有include "space.h"的代码以及这段代码前面是否用宏定义控制了!我使用的方法是直接在整个gcc源码目录()以及isl的头文件路径下"grep “space.h” -r ",然而并没有找到,这说明确实没有include “space.h”,这就非常奇怪了;就只能猜测我自己安装的isl有什么问题;然后通过sudo apt-get install libisl-dev安装一个isl,并使用这个isl(先卸载/home/lb/workspace/com中的isl),然后在重新按照上面的方法编译gcc,就这么编译通过了!通过检查apt-get安装的isl以及我自己编译安装的isl,发现:[1]版本不同,[2],通过"grep “space.h” -r "发现系统的(apt-get 安装)中有多个头文件里面include “space.h”;这说明了了确实有可能我自己编译的isl有问题;在使用上面提到的方法只预编译graphite-optimize-isl.c发现确实这次编译中也include “space.h”;
所以确实是我编译的isl问题;但是我isl编译是严格遵循规则的啊!难道isl版本太高(我编译的是isl-0.20),通过换成低版本的isl发现确实没有问题了!这就很奇怪了,明明gcc-8.1上的要求就是只要isl-0.15以上就好啊,为什么isl-0.20不行!其实想想怎么可能无限兼容高版本,假如我是2018年写的gcc-8.1,但是isl那时候是isl-0.19,根本就没法测试使用isl-0.20来编译gcc-8.1,而且如果isl-0.20较isl-0.19有大的更新(引用方式,函数接口改变),那么肯定就会导致无法给gcc-8.1使用了!就想现在的一样,isl-0.20较旧版本的很多头文件里面没引用space.h了!

总结:犯了两个错:

1,configure的时候指定isl只要–with-isl=/home/lb/workspace/com
而–with-isl-include=/home/lb/workspace/com/include/可有可无,但是千万别指定为–with-isl-include=/home/lb/workspace/com/include/isl(isl的使用可不是这样的);
2,isl版本太高(对于编译gcc-8.1,isl-0.20版本太高了);

isl导致编译gcc-8.1出现错误相关推荐

linux下编译isl,CentOS 6 编译GCC 4.8.1简明流程
之前讨论了很多关于编译gcc的事情,都源自于当年在CentOS6.2上编译gcc4.7.2的事情,简直苦不堪言. 今天工作需要又要用CentOS了,用于gcc只用了更严格的开源协议GPL v3的问题, ...
cv_bridge与python版本问题导致编译错误error: return-statement with no value, in function returning ‘void*’ [-fpe
1.先说一下报错的过程(着急看解决过程的直接看第二点): 首先,在使用OpenCV时候,报错如下: [ERROR] [1663728000.010723, 6019.022000]: bad call ...
gcc中extra qualification错误
gcc中extra qualification错误 g++编译错误error: extra qualification 'SQSBase::' on member 'parseResponse'等类似 ...
Ubuntu 12.04 64bit 安装编译GCC 4.1.2 绝对原创
1. 下载并解压源代码: wget http://mirrors.ustc.edu.cn/gnu/gcc/gcc-4.1.2/gcc-4.1.2.tar.bz2 tar jxvf gcc-4.1.2. ...
编译mysql4.0时候出现错误提示checking LinuxThreads... Not found
编译mysql4.0时候出现错误提示checking "LinuxThreads"... "Not found" 2009-06-30 18:25 解压mysq ...
centos 下编译 gcc
由于PHP7在编译过程需要的GCC版本比较高,而在 wdlinux 中自带的 gcc 版本满足不了PHP7的编译需求,因此这里才有了 gcc 的编译过程实际上在编译 gcc 的过程中又遇到了好多坑, ...
在64位Ubuntu上编译32位程序常见错误
问题1: 找不到头文件 asm/errno.h 解决办法 : [/usr/lib/gcc$ ]sudo ln -s x86_64-linux-gnu/asm asm 问题2:找不到gcc ...
解决Windows上编译PHP7.1拓展的错误
转载请注明文章出处:https://tlanyan.me/solve-buil... 接上篇Windows编译PHP7.2拓展,以为编译PHP7.1的拓展应该水到渠成,马到成功.哪知道编译PHP7.1 ...
ROS-Melodic 编译Moveit全过程记录和错误解决方案
ROS-Melodic 编译Moveit全过程记录和错误解决方案在Ros Melodic版本下,直接运行sudo apt-get install ros-melodic-moveit会出现以下错误: ...

isl导致编译gcc-8.1出现错误

isl导致编译gcc-8.1出现错误相关推荐

最新文章

热门文章