make uImage的时候出错

【问题】

在别人提供的linux环境下，设置好了交叉编译器后，用：

make ARCH=arm uImage

去编译linux kernel，结果编译最后的阶段，出错了：

scripts/unifdef.c:209: error: conflicting types for ‘getline’
/usr/include/stdio.h:653: note: previous declaration of ‘getline’ was
here
make[2]: *** [scripts/unifdef] Error 1
make[1]: *** [__headers] Error 2
make: *** [vmlinux] Error 2

当时由于时间有限，未能解决此问题。

现在有空了，专门来看看此问题，到底是啥原因出错的。

【解决过程】

1.网上找了半天，最后通过BuildRoot Compile 的問題找到：

其解释了原因：

Rawhide builds are currently failing to build unifdef.c, as the next
version of glibc changes the default _POSIX_C_SOURCE level, which
exposes getline() from

对应的解决办法是：

Rename the symbol in unifdef.c to parseline to avoid this conflicting
declaration.

即，将unifdef.c中的getline改个名字，比如parseline，即可。

如此，已避免和glic从中所导出的getline() 相冲突。

对应的patch为：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

diff --git a/scripts/unifdef.c b/scripts/unifdef.c  index 552025e..977e682 100644  --- a/scripts/unifdef.c  +++ b/scripts/unifdef.c  @@ -206,7 +206,7 @@ static void done(void);  static void error(const char *);  static int findsym(const char *);  static void flushline(bool);  -static Linetype getline(void);  +static Linetype parseline(void);  static Linetype ifeval(const char **);  static void ignoreoff(void);  static void ignoreon(void);  @@ -512,7 +512,7 @@ process(void)    for (;;) {  linenum++;  - lineval = getline();  + lineval = parseline();  trans_table[ifstate[depth]][lineval]();  debug("process %s -> %s depth %d",  linetype_name[lineval],  @@ -526,7 +526,7 @@ process(void)  * help from skipcomment().  */  static Linetype  -getline(void)  +parseline(void)  {  const char *cp;  int cursym;

 

或者，也可以通过将类似于：

-D_POSIX_C_SOURCE=200112L

的参数传递给unifdef的CFLAGS来绕过此问题。

当然，此法不是好的长期解决的方案。

2.另外,这里:

也解释了该问题.并且也解释说明了,此bug在新版linux中已经解决了.

 

【总结】

这样的问题，作为普通用户来说，真的是属于变态的问题。

也是众所周知的linux下面的各种版本的各种库的不兼容问题的最佳例子。

搞得新旧版本的基本的编译，都会有问题。还是要找明白内幕的人，才能解释的清楚的。

否则普通用户，也不知道getline是啥作用，也不敢随便乱改啊。

【后记】

再多说一句,这是人家09年发现并解决了的bug,结果咱中国2012年了,还能遇到此bug,真是无语了…

然后又去查了下，原来出错也是有原因的。

当时用的系统（记得好像是）2.6.28的某个版本的，而2.6.28的稳定版，网上找了下，比如：

其时间是2008-12-30，也就是2009年前后，所以，上面别人遇到此bug并解决此bug的时候，正好是2009年，而我们此处用2.6.28的话，自然也会遇到同样问题。

所以，归根结题的问题根源在于，如果可以的话，就不该使用这么老的linux，或者如果使用的话，那么就应该先解决掉此问题，然后再给我们使用。