2014-10-18 162 views
1

我想编译uClibc 0.9.33.2为我的旧路由器Ubicom IP7k处理器。由于架构并未得到GCC和uClibc的正式支持,我必须自己移植它,并使用处理器供应商的GCC(ubicom32-uclinux-gcc (GCC) 4.4.1 20100320 (stable))的修改版本。一切都很好,直到GCC向我展示了一个奇怪的错误。GCC无法编译正确的代码

CC libc/sysdeps/linux/common/fstatat.os 
In file included from libc/sysdeps/linux/common/xstatconv.h:26, 
       from libc/sysdeps/linux/common/fstatat.c:11: 
./include/bits/kernel_stat.h:25: error: expected ':', ',', ';', '}' or '__attribute__' before '.' token 
./include/bits/kernel_stat.h:52: error: expected ':', ',', ';', '}' or '__attribute__' before '.' token 
make: *** [libc/sysdeps/linux/common/fstatat.os] Error 1 

kernel_stat.h:

#ifndef _BITS_STAT_STRUCT_H 
#define _BITS_STAT_STRUCT_H 

#ifndef _LIBC 
#error bits/kernel_stat.h is for internal uClibc use only! 
#endif 

/* This file provides whatever this particular arch's kernel thinks 
* struct kernel_stat should look like... It turns out each arch has a 
* different opinion on the subject... */ 

struct kernel_stat { 
    unsigned short st_dev; 
    unsigned short __pad1; 
    unsigned long st_ino; 
    unsigned short st_mode; 
    unsigned short st_nlink; 
    unsigned short st_uid; 
    unsigned short st_gid; 
    unsigned short st_rdev; 
    unsigned short __pad2; 
    unsigned long st_size; 
    unsigned long st_blksize; 
    unsigned long st_blocks; 
    unsigned long st_atime;   <-- error occurs here 
    unsigned long __unused1; 
    unsigned long st_mtime; 
    unsigned long __unused2; 
    unsigned long st_ctime; 
    unsigned long __unused3; 
    unsigned long __unused4; 
    unsigned long __unused5; 
}; 

struct kernel_stat64 { 
    unsigned char __pad0[6]; 
    unsigned short st_dev; 
    unsigned char __pad1[4]; 
#define _HAVE_STAT64___ST_INO 
    unsigned long __st_ino; 
    unsigned int st_mode; 
    unsigned int st_nlink; 
    unsigned long st_uid; 
    unsigned long st_gid; 
    unsigned char __pad2[6]; 
    unsigned short st_rdev; 
    unsigned char __pad3[4]; 
    long long st_size; 
    unsigned long st_blksize; 
    unsigned long st_blocks; /* Number 512-byte blocks allocated. */ 
    unsigned long __pad4;  /* future possible st_blocks high bits */ 
    unsigned long st_atime;   <-- and here 
    unsigned long __pad5; 
    unsigned long st_mtime; 
    unsigned long __pad6; 
    unsigned long st_ctime; 
    unsigned long __pad7;  /* will be high 32 bits of ctime someday */ 
    unsigned long long st_ino; 
}; 

#endif /* _BITS_STAT_STRUCT_H */ 

到底出了什么这里有没有什么办法解决它,而不必更新GCC?

+4

你可以看一看'gcc -E'生成的输出在预处理后查看实际的源代码,看看是否会引发任何麻烦的宏扩展... – vanza 2014-10-18 22:27:29

+1

宏 - 那些有时​​会使得合理的东西将代码看成完全不同的东西。由于几乎每次我看到“预期”:',',',',','...错误是由于宏观问题导致的,我希望诊断在某些原因中会提到宏。与此同时,我在脑海里陷入了错误和宏观之间的联系。 – 2014-10-18 22:50:46

回答

4

st_atime等不能成为struct stat的成员。相反,它们是扩展为st_atim.tv_sec等的宏(注意缺少最终的e)和st_atim等是类型为struct timespec的成员。内核有这个错误,只是在struct stat的概念中重新创建了相同的布局平面,但您必须以对用户空间正确的方式进行。